Hi!
...
> That setup sounds nice! What is your workflow to import a new upstream
> release?
>
> I see the watch file still points to the tarball:
>
> https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/watch
>
> Would it be possible to extend the debian/watch syntax t
On Sun, 06 Oct 2024 at 10:02:56 +0200, Simon Josefsson wrote:
> Otto Kekäläinen writes:
> > git-buildpackage supports dual import from both upstream git and
> > tarball to maximize supply chain auditability.
>
> That setup sounds nice! What is your workflow to import a new upstream
> release?
T
Otto Kekäläinen writes:
>> No objections to have this kind of capability, but I still strongly
>> believe that importing tar archives is highly suboptimal and directly
>> branching off the upstream git repository is an highly superior workflow
>> and should be used as much as possible.
>>
>> This
On Oct 06, Otto Kekäläinen wrote:
> Also some projects release tarballs with extra additions that are not
> in the same git, or they strip away directories/files that are in git,
I am sure that there are counterexamples, but usually they exclude
things that we want to rebuild anyway, like config
> No objections to have this kind of capability, but I still strongly
> believe that importing tar archives is highly suboptimal and directly
> branching off the upstream git repository is an highly superior workflow
> and should be used as much as possible.
>
> This being said, I maintain some pac
No objections to have this kind of capability, but I still strongly
believe that importing tar archives is highly suboptimal and directly
branching off the upstream git repository is an highly superior workflow
and should be used as much as possible.
This being said, I maintain some packages wh
Stefano Rivera writes:
> Should we expand this to include some of these new mechanisms?
> Things brought up in the debian-python thread include:
> 1. sigstore https://docs.sigstore.dev/
> 2. ssh signatures
> 3. signify https://man.openbsd.org/signify.1
+1
I believe all signatures we trust shoul
On 2024-10-05 03:32, Guillem Jover wrote:
> For an example of the activity that is going on in the OpenPGP ecosystem,
> here's a list of some of the non-GnuPG implementations already present
> in Debian, by programming language:
Thanks for the list! I was aware of some of them, but not all.
> *
Hi Guillem (2024.10.05_01:32:45_+)
> > 1. sigstore https://docs.sigstore.dev/
>
> Although I've heard of this before, I never really checked what is
> the actual design behind it, and its implications.
I'm new to all this too, but I can answer some of those questions from
my own reading:
> I
Hi!
On Fri, 2024-10-04 at 18:21:01 +, Stefano Rivera wrote:
> Picking up a thread that started on debian-pyt...@lists.debian.org:
> https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea
>
> Upstreams that care about supply chain security have been building
> mechanisms to authenti
* Stefano Rivera: " Alternative signature mechanisms for upstream source
verification" (Fri, 4 Oct 2024 18:21:01 +):
[...]
> Should we expand this to include some of these new mechanisms?
> Things brought up in the debian-python thread include:
> 1. sigstore https://doc
Picking up a thread that started on debian-pyt...@lists.debian.org:
https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea
Upstreams that care about supply chain security have been building
mechanisms to authenticate their releases, beyond PGP signatures.
For example, Python started pro
12 matches
Mail list logo
