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
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
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
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
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
> > 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,
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
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
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
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,
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
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
>
> 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
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
[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
> 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
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
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
25 matches
Mail list logo
