Hi,
Skyler Ferris skribis:
> In short, I'm not sure that we actually get any value from checking the
> PGP signature for most projects. Either HTTPS is good enough or the
> attacker won. 99% of the time HTTPS is good enough (though it is notable
> that the remaining 1% has a disproportionate
On 4/13/24 05:47, Giovanni Biscuolo wrote:
> Hello Skyler,
>
> Skyler Ferris writes:
>
>> On 4/12/24 23:50, Giovanni Biscuolo wrote:
>>> general reminder: please remember the specific scope of this (sub)thread
> [...]
>
>>> (https://yhetil.org/guix/8734s1mn5p@xelera.eu/)
>>>
>>> ...and if need
Hi all,
On 4/11/24 06:49, Andreas Enge wrote:
> Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga:
>> I think it's just better to
>> obtain the exact same code that is easy to find
> The exact same code as what? Actually I often wonder when looking for
> a project and end up with a G
Hi again,
On 4/12/24 23:50, Giovanni Biscuolo wrote:
> Hello,
>
> general reminder: please remember the specific scope of this (sub)thread
>
> --8<---cut here---start->8---
>
> Please consider that this (sub)thread is _not_ specific to xz-utils but
> to the
Hello Skyler,
Skyler Ferris writes:
> On 4/12/24 23:50, Giovanni Biscuolo wrote:
>> general reminder: please remember the specific scope of this (sub)thread
[...]
>> (https://yhetil.org/guix/8734s1mn5p@xelera.eu/)
>>
>> ...and if needed read that message again to understand the context,
>
Hi Attila,
sorry for the delay in my reply,
I'm asking myself if this (sub)thread should be "condensed" in a
dedicated RFC (are RFCs official workflows in Guix, now?); if so, I
volunteer to file such an RFC in the next weeks.
Attila Lendvai writes:
>> Are there other issues (different from the
Hello,
general reminder: please remember the specific scope of this (sub)thread
--8<---cut here---start->8---
Please consider that this (sub)thread is _not_ specific to xz-utils but
to the specific attack vector (matrix?) used to inject a backdoor in a
bina
Hello,
Ludovic Courtès writes:
> Ekaitz Zarraga skribis:
>
>> On 2024-04-04 21:48, Attila Lendvai wrote:
>>> all in all, just by following my gut insctincts, i was advodating
>>> for building everything from git even before the exposure of this
>>> backdoor. in fact, i found it surprising as a
Hi!
Andreas Enge skribis:
> Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès:
>> I think we should gradually move to building everything from
>> source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
>
> the big drawback of this approach is that we would lose ma
> > I think we should gradually move to building everything from
> > source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
>
>
> the big drawback of this approach is that we would lose maintainers'
> signatures, right?
it's possible to sign git commits and (annotated) tags, t
Hi,
and everybody is reading.
This is a steep claim! I agree that nobody reads generated files in
a release tarball, but I am not sure how many other files are actually
read.
Yea, it is. I'd also love to know how effective is the reading in a
release tarball vs a VCS repo. Quality of the re
Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga:
> I think it's just better to
> obtain the exact same code that is easy to find
The exact same code as what? Actually I often wonder when looking for
a project and end up with a Github repository how I could distinguish
the "original
Hi,
On 2024-04-11 14:43, Andreas Enge wrote:
Hello,
Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès:
I think we should gradually move to building everything from
source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
the big drawback of this approach is tha
Hello,
Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès:
> I think we should gradually move to building everything from
> source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
the big drawback of this approach is that we would lose maintainers'
signatures, right
Hi,
Ekaitz Zarraga skribis:
> On 2024-04-04 21:48, Attila Lendvai wrote:
>> all in all, just by following my gut insctincts, i was advodating
>> for building everything from git even before the exposure of this
>> backdoor. in fact, i found it surprising as a guix newbie that not
>> everything i
On Thu, 04 Apr 2024 12:34:42 +0200
Giovanni Biscuolo wrote:
> Hello everybody,
>
> I know for sure that Guix maintainers and developers are working on
> this, I'm just asking to find some time to inform and possibly discuss
> with users (also in guix-devel) on what measures GNU Guix - the
> soft
> Are there other issues (different from the "host cannot execute target
> binary") that makes relesase tarballs indispensable for some upstream
> projects?
i didn't mean to say that tarballs are indispensible. i just wanted to point
out that it's not as simple as going through each package defi
Hi Attila and guix-security team,
Attila Lendvai writes:
>> Are really "configure scripts containing hundreds of thousands of lines
>> of code not present in the upstream VCS" the norm?
>
> pretty much for all C and C++ projects that use autoconf... which is
> numerous, especially among the core
[mu4e must have changed the key bindings for replies, so here is my mail
again, this time as a wide reply.]
Giovanni Biscuolo writes:
> So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of
> tampered .m4 macros (and other possibly tampered build configuration
> script)?
>
> IMHO
Hi,
I just want to add some perspective from the bootstrapping.
On 2024-04-04 21:48, Attila Lendvai wrote:
all in all, just by following my gut insctincts, i was advodating for building
everything from git even before the exposure of this backdoor. in fact, i found
it surprising as a guix ne
> Are really "configure scripts containing hundreds of thousands of lines
> of code not present in the upstream VCS" the norm?
pretty much for all C and C++ projects that use autoconf... which is numerous,
especially among the core GNU components.
> If so, can we consider hundreds of thousand
Hi Attila,
Attila Lendvai writes:
>> Also, in (info "(guix) origin Reference") I see that Guix packages
>> can have a list of uri(s) for the origin of source code, see xz as an
>> example [7]: are they intended to be multiple independent sources to
>> be compared in order to prevent possible tam
Hello,
a couple of additional (IMO) useful resources...
Giovanni Biscuolo writes:
[...]
> Let me highlight this: «It is pragmatically impossible [...] to peer
> review a tarball prepared in this manner.»
>
> There is no doubt that the release tarball is a very weak "trusted
> source" (trusted
> Also, in (info "(guix) origin Reference") I see that Guix packages can have a
> list of uri(s) for the origin of source code, see xz as an example [7]:
> are they intended to be multiple independent sources to be compared in
> order to prevent possible tampering or are they "just" alternatives to
Hello everybody,
I know for sure that Guix maintainers and developers are working on
this, I'm just asking to find some time to inform and possibly discuss
with users (also in guix-devel) on what measures GNU Guix - the software
distribution - can/should deploy to try to avoid this kind of attacks
> >> Is there a way we can blacklist known bad versions?
>
> I'm not sure what you mean, but I don't think so.
For beginning, what about adding a short comment:
diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 5de17b6b51..fd5ab7ba00 100644
--- a/gnu/packages/compress
Tomas Volf <~@wolfsden.cz> writes:
> On 2024-03-29 13:39:59 -0700, Felix Lechner via Development of GNU Guix and
> the GNU System distribution. wrote:
>> > Is there a way we can blacklist known bad versions?
>>
>> Having said all that, I am not sure Guix is affected.
>>
>> On my systems, the 'd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
-BEGIN PGP SIGNATURE-
iQJRBAEBCgA7FiEEpCB7VsJVEJ8ssxV+SZCXrl6oFdkFAmYHK0sdHGpvaG4ua2Vo
YXlpYXNAcHJvdG9ubWFpbC5jb20ACgkQSZCXrl6oFdkFRA//WaJMegtHd88wlq0V
QovAYD7+d6zj5DxgVTiGKXckyKWx7AceVJ0WVp9MB+WxU8dEXepEnd9AHOA4v/Fb
HLy4prms+noIpXqHW5y6EDg
Hello,
On 2024-03-29 13:39:59 -0700, Felix Lechner via Development of GNU Guix and the
GNU System distribution. wrote:
> > Is there a way we can blacklist known bad versions?
>
> Having said all that, I am not sure Guix is affected.
>
> On my systems, the 'detect.sh' script shows no referece to l
Hi Ryan,
On Fri, Mar 29 2024, Ryan Prior wrote:
> I'm reading today that a backdoor is present in xz's upstream tarball
> (but not in git), starting at version 5.6.0. Source:
> https://www.openwall.com/lists/oss-security/2024/03/29/4
Thanks for sending this! This is an extremely serious vulnera
I'm reading today that a backdoor is present in xz's upstream tarball (but not
in git), starting at version 5.6.0. Source:
https://www.openwall.com/lists/oss-security/2024/03/29/4
Guix currently packages xz-utils 5.2.8 as "xz" using the upstream tarball. Is
there a way we can blacklist known ba
31 matches
Mail list logo