Russ Allbery wrote:
[...]
There is extensive ongoing discussion of this on debian-devel. There's no
real consensus in that discussion, but I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in
Jose E. Marchesi wrote:
Jose E. Marchesi wrote:
[...]
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
The issue seems to be releases containing binary data for
Zack Weinberg wrote:
[...] but I do think there's a valid point here: the malicious xz
maintainer *might* have been caught earlier if they had committed the
build-to-host.m4 modification to xz's VCS.
That would require someone to notice that xz.git has a build-to-host.m4
that does not exist
Jacob Bachmeyer writes:
> The m4 files were not checked into the repository, instead being added
> (presumably by running autogen.sh with a rigged local m4 file
> collection) while preparing the release.
Ah, yes, I think you are correct. For some reason I thought the
legitimate
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> `distcheck` target's prominence to recommend it in the "Standard
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I was recently reading about the backdoor announced in xz-utils the
> other
Bruno Haible wrote:
Jacob Bachmeyer wrote:
some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly that, and
Zack Weinberg wrote:
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
"Zack Weinberg" writes:
It might indeed be worth thinking about ways to minimize the
difference between the tarball "make dist" produces and the tarball
"git archive" produces, starting from the same clean git
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote:
>
> Russ Allbery wrote:
> > [...]
> >
> > There is extensive ongoing discussion of this on debian-devel. There's no
> > real consensus in that discussion, but I think one useful principle that's
> > emerged that doesn't disrupt the world
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Essentially, this would be an automated release building service: upon
request, make a Git checkout, run autogen.sh or equivalent, make dist,
and publish or hash the result. The problem is that an attacker who
manages to gain commit access to a
> Jose E. Marchesi wrote:
>>> [...]
>>>
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
>>> The issue seems to be releases containing binary data for unit tests,
>>>
"Zack Weinberg" writes:
> I have been thinking about this incident and this thread all weekend and
> have seen a lot of people saying things like "this is more proof that
> tarballs are a thing of the past and everyone should just build straight
> from git". There are a bunch of reasons why one
On Sun, Mar 31, 2024 at 6:19 PM Peter Johansson wrote:
>
>
> On 1/4/24 06:00, Eric Gallager wrote:
>
> So, `aclocal` has a flag to control this behavior: specifically, its
> `--install` flag. Right now I don't see `aclocal` mentioned in the GNU
> Coding Standards at all. Should they be updated to
On Mon, Apr 1, 2024 at 2:26 PM Zack Weinberg wrote:
>
> On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> > "Zack Weinberg" writes:
> >> It might indeed be worth thinking about ways to minimize the
> >> difference between the tarball "make dist" produces and the tarball
> >> "git archive"
Eric Gallager wrote:
> What about a 3rd one of these prefixes: "novcs", to teach automake
> about which files belong in VCS or not? i.e. then you might have a
> variable name like:
> dist_novcs_DATA = foo bar baz
> ...which would indicate that foo, bar, and baz are data files that
> ought to be
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> "Zack Weinberg" writes:
>> It might indeed be worth thinking about ways to minimize the
>> difference between the tarball "make dist" produces and the tarball
>> "git archive" produces, starting from the same clean git checkout,
>> and also
On Sun, Mar 31, 2024, at 3:17 AM, Jacob Bachmeyer wrote:
> Eric Gallager wrote:
>> Specifically, what caught my attention was how the release tarball
>> containing the backdoor didn't match the history of the project in its
>> git repository. That made me think about automake's `distcheck`
>>
* Such an automated release building service is a piece of SaaSS.
CI is not SaaSS, how is it different?
I can
hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse
than, proprietary software" and at the same time advocate the use of
such a service.
Jacob Bachmeyer wrote:
> >> Essentially, this would be an automated release building service: upon
> >> request, make a Git checkout, run autogen.sh or equivalent, make dist,
> >> and publish or hash the result. The problem is that an attacker who
> >> manages to gain commit access to a
Jacob Bachmeyer wrote:
> some of the blame for this needs to fall on the
> systemd maintainers and their "katamari" architecture. There is no good
> reason for notifications of daemon startup to pull in liblzma, but using
> libsystemd for that purpose does exactly that, and ended up getting
>
I am not arguing for the building service, but:
On 2024-04-01 14:40:20 +0200, Bruno Haible wrote:
> * Such an automated release building service is a piece of SaaSS. I can
> hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse
> than, proprietary software" and at the same
21 matches
Mail list logo
