On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí wrote:
> On Saturday, 6 April 2024 18:22:22 CEST Sven Brauch wrote:
> > This is basically a discussion about whether it is less risky to trust
> > the individual developers, or the people with access to the CI signing
> > key. You are trading
On Saturday, 6 April 2024 18:22:22 CEST Sven Brauch wrote:
> This is basically a discussion about whether it is less risky to trust
> the individual developers, or the people with access to the CI signing
> key. You are trading likeliness of there being one bad actor vs. impact
> one bad actor can
Hi from the peanut gallery,
The xz tarball was only a (minor) part of the problem. A big part of the
backdoor was entirely in git and would be probably also usable if
something else would have been added.
Also, this tight coupling to git makes me uneasy. I like git and it's
one of the best
Am Samstag, 6. April 2024, 18:22:22 CEST schrieb Sven Brauch:
> Hi,
>
> On 06.04.24 13:07, Marc Deop i Argemí wrote:
>
> > If you automate things, everything can be reviewed/validated by more than
> > one
> > entity and thus increasing security.
> >
> > The CI can be reviewed and audited but
Hi,
On 06.04.24 13:07, Marc Deop i Argemí wrote:
If you automate things, everything can be reviewed/validated by more than one
entity and thus increasing security.
The CI can be reviewed and audited but your personal laptop and your workflow
cannot.
This is basically a discussion about
On Friday, 5 April 2024 13:45:35 CEST Carl Schwan wrote:
> I disagree. I want my tarball to be signed with my GPG key stored in my
> Yubiky and not by a generic KDE key. It should be a proof that I as a
> maintainer of a project did the release and not someone else. Same with the
> upload to
On Sat, Apr 6, 2024 at 4:23 AM Johannes Zarl-Zierl
wrote:
> Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan:
> > On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote:
> > > - Tarballs should only be generated in a reproducible manner using
> > > scripts. Ideally by
On Sat, Apr 6, 2024 at 1:43 AM Heiko Becker wrote:
> On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote:
> > It seems a lot of people feel conservative in favor of tarballs, so
> > maybe I aimed too far. At least I think the discussion brought some
> > interesting points that we
Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan:
> On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote:
> > - Tarballs should only be generated in a reproducible manner using
> > scripts. Ideally by the CI only.
> > - We should start to sign tarballs in the CI.
>
> I
On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote:
It seems a lot of people feel conservative in favor of tarballs, so
maybe I aimed too far. At least I think the discussion brought some
interesting points that we can explore further. Some I identified:
- The tarballs should
On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote:
> It seems a lot of people feel conservative in favor of tarballs, so
> maybe I aimed too far. At least I think the discussion brought some
> interesting points that we can explore further. Some I identified:
>
> - The tarballs
On Freitag, 5. April 2024 12:04:28 CEST Albert Vaca Cintora wrote:
> It seems a lot of people feel conservative in favor of tarballs, so
> maybe I aimed too far. At least I think the discussion brought some
> interesting points that we can explore further. Some I identified:
>
> - The tarballs
It seems a lot of people feel conservative in favor of tarballs, so
maybe I aimed too far. At least I think the discussion brought some
interesting points that we can explore further. Some I identified:
- The tarballs should contain no changes with respect to git, or
minimal changes obviously
On piatok 5. apríla 2024 9:04:14 CEST Tobias Leupold wrote:
> Am 05.04.24 um 06:25 schrieb Juraj Oravec:
> > Hello Albert,
> >
> > The release tarballs can be signed with GPG (or is it PGP?) which
> > provide another layer of protection to make sure the release is
> > authenthic.
> >
> > If KDE
Am 05.04.24 um 06:25 schrieb Juraj Oravec:
On streda 3. apríla 2024 18:34:04 CEST Albert Vaca Cintora wrote:
Hi KDE folks,
The recent xz backdoor scandal made me realize how bad and obsolete
distributing tarballs is. The source of truth for our code are the
repositories, and releases can
On streda 3. apríla 2024 18:34:04 CEST Albert Vaca Cintora wrote:
> Hi KDE folks,
>
> The recent xz backdoor scandal made me realize how bad and obsolete
> distributing tarballs is. The source of truth for our code are the
> repositories, and releases can simply be tags on those repos.
>
> As a
On Thursday 4 April 2024 04:26:57 PDT Sune Vuorela wrote:
> 'does it use autotools?'
The outcome of this is "please migrate off Autotools".
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel DCAI Cloud Engineering
On Thursday, 4 April 2024 13:26:57 CEST, Sune Vuorela wrote:
On 2024-04-04, Ben Cooksley wrote:
I do also think it is nice if we get someone else to verify that the
tarball we ship actually matches the tag. I think some people in
distributions have already started looking into verifying that.
On Thursday, 4 April 2024 13:07:42 CEST, Ben Cooksley wrote:
[snip]
As an additional aside - we don't currently GPG sign our Git tags, so there
is nothing validating that the person who made the release is actually the
person whose name is on it.
With GPG signatures we can at least validate who
Neal Gompa 于 2024年4月4日周四 22:19写道：
>
> That's fair, but they are not permanent and can be reaped when they're
> not referenced by anything anymore.
>
If you pull these release commits in a "download" server and restrict write
access to it, not giving everyone permission to delete a tag, just
On Thu, Apr 4, 2024 at 10:18 AM Jin Liu wrote:
>
>
> Neal Gompa 于 2024年4月4日周四 22:09写道：
> > and because Git has no immutability
> guarantees, it's not exactly ideal as an input either.
>
> Commits and trees in git are immutable. Refs like tags and branches are not.
That's fair, but they are not
Neal Gompa 于 2024年4月4日周四 22:09写道：
> and because Git has no immutability
guarantees, it's not exactly ideal as an input either.
Commits and trees in git are immutable. Refs like tags and branches are not.
On Thu, Apr 4, 2024 at 9:52 AM Harald Sitter wrote:
>
> On Thu, Apr 4, 2024 at 3:38 PM Tobias Leupold wrote:
> >
> > Am 04.04.24 um 13:25 schrieb Harald Sitter:
> > > On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote:
> > >> Just what comes into my mind at once. A release is not always only
On Thu, Apr 4, 2024 at 3:38 PM Tobias Leupold wrote:
>
> Am 04.04.24 um 13:25 schrieb Harald Sitter:
> > On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote:
> >> Just what comes into my mind at once. A release is not always only a git
> >> tag.
> >
> > Doesn't that make your source tarball a
Am 04.04.24 um 13:25 schrieb Harald Sitter:
On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote:
Just what comes into my mind at once. A release is not always only a git tag.
Doesn't that make your source tarball a derived work from the source
in your git tag?
Yes, of course! this was the
The tree-id of a git commit is effectively a checksum of all files. So you
can ask packagers to pull a specific commit and verify either commit-id or
tree-id. No extra verification step needed.
Sune Vuorela 于 2024年4月4日周四 17:48写道：
> On 2024-04-03, Albert Vaca Cintora wrote:
> > What's the
On 2024-04-04, Ben Cooksley wrote:
>> I do also think it is nice if we get someone else to verify that the
>> tarball we ship actually matches the tag. I think some people in
>> distributions have already started looking into verifying that.
>>
>
> Hopefully they'll be gentle with tooling that
On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote:
> Just what comes into my mind at once. A release is not always only a git tag.
Doesn't that make your source tarball a derived work from the source
in your git tag?
On Thu, Apr 4, 2024 at 10:48 PM Sune Vuorela wrote:
> On 2024-04-03, Albert Vaca Cintora wrote:
> > What's the advantage of providing tarballs?
>
> I do think there is an advantage in being able to verify that the soure
> tarball is the same across distributions. Using a checksum on the
>
E-Mail von Albert Vaca Cintora vom Mittwoch, 3. April 2024, 18:34:04 CEST:
> Hi KDE folks,
>
> The recent xz backdoor scandal made me realize how bad and obsolete
> distributing tarballs is. The source of truth for our code are the
> repositories, and releases can simply be tags on those repos.
>
On 2024-04-03, Albert Vaca Cintora wrote:
> What's the advantage of providing tarballs?
I do think there is an advantage in being able to verify that the soure
tarball is the same across distributions. Using a checksum on the
tarball is an easy way of doing it. Different git invocations for git
31 matches
Mail list logo
