On Fri, Apr 05, 2024 at 01:30:51AM +0200, kpcyrd wrote:
> On 4/5/24 12:31 AM, Adrian Bunk wrote:
> > Hashes of "git archive" tarballs are anyway not stable,
> > so whatever a maintainer generates is not worse than what is on Github.
> >
> > Any proper tooling would have to verify that the
On 4/5/24 12:31 AM, Adrian Bunk wrote:
Hashes of "git archive" tarballs are anyway not stable,
so whatever a maintainer generates is not worse than what is on Github.
Any proper tooling would have to verify that the contents is equal.
...
Being able to disregard the compression layer is still
On Fri, Apr 05, 2024 at 01:31:25AM +0300, Adrian Bunk wrote:
> On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
> >...
> > I've checked both, upstreams github release page and their website[1], but
> > couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> > the
On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
>...
> I've checked both, upstreams github release page and their website[1], but
> couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> the compression is fair.
>
> [1]: https://www.vim.org/download.php
>...
Perhaps
On 4/3/24 4:21 AM, Adrian Bunk wrote:
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
...
I figured out a somewhat straight-forward way to check if a given `git
archive` output is cryptographically claimed to be the source input of a
given binary package in either Arch Linux or Debian
> On Apr 2, 2024, at 1:11 PM, John Gilmore wrote:
>
> For me, the distinction is that the local storage is under the direct
> control of the person trying to rebuild, while the network and the
> servers elsewhere in the network are not. If local storage is
> unreliable, you can fix or
