Russ,
Thank you for this summary.
On Friday, June 21, 2024 3:24:58 PM MST Russ Allbery wrote:
> There is a stark disagreement over the importance of that signature, and
> it appears to be the remaining blocking issue. I have argued that it
> makes little difference from a security standpoint whe
Hello,
On Fri 21 Jun 2024 at 12:40pm -07, Russ Allbery wrote:
> This is the soapbox that I climb onto whenever a GR is proposed, and I
> guess I need to climb onto it again. More fundamentally than my position
> on any given GR, I am on team closure. One of the worst and, I would
> argue, actua
Over the past week and a half, we've had a sprawling thread of nearly
unreadable volume that I am sure many people have stopped reading for very
understandable reasons. As probably the largest single contributor to
that volume, I will attempt to do penance and summarize the thread for
everyone els
Scott Kitterman writes:
> I think it would be better to reset and actually have the conversation
> that was assumed to have happened before taking the step of a GR.
We're having that conversation right now. I see no reason to stop now
that it's finally started in earnest unless it looks like it
On June 21, 2024 6:35:48 PM UTC, Russ Allbery wrote:
>Scott Kitterman writes:
>
>> This whole thread is about a draft GR to override a FTP Master decision
>> based on a claim that they had refused to engage with the tag2upload
>> developers for years to explain their concerns or work on resolv
Ansgar 🙀 writes:
> The only published branch (debian/unstable) looks like it would be
> trivial to for git-debpush to compute an integrity hash as suggested
> using only a bit shell around Git commands (no dpkg, dgit or anything)?
> (AFAIU git-debpush would already check that patches apply cleanl
Scott Kitterman writes:
> This whole thread is about a draft GR to override a FTP Master decision
> based on a claim that they had refused to engage with the tag2upload
> developers for years to explain their concerns or work on resolving
> them.
> None of that turned out to be accurate.
tag2up
Hi,
On Fri, 2024-06-21 at 18:42 +0200, Matthias Urlichs wrote:
> On 21.06.24 17:37, Ansgar 🙀 wrote:
> > I also wrote:
> >
> > > (Please also consider in your reply the suggested changes to make
> > > hashing possible/easier...)
> >
> > Did you consider that in your new analysis? If yes, how?
>
Hi,
On Fri, 2024-06-21 at 09:26 -0700, Russ Allbery wrote:
> Ansgar 🙀 writes:
>
> > I would still like to understand how your packages would not work with
> > the suggested integrity check. Could you give an example, possibly with
> > a reference to a Git repository as well?
>
> https://tracker
On June 21, 2024 4:26:41 PM UTC, Russ Allbery wrote:
>Ansgar 🙀 writes:
>> On Fri, 2024-06-21 at 08:29 -0700, Russ Allbery wrote:
>
>>> Wait, why would I ever want to upload a 3.0 (native) package for a
>>> non-native package with the tooling as it is today in Debian?
>
>> As far as I understan
On 21.06.24 17:37, Ansgar 🙀 wrote:
I also wrote:
| (Please also consider in your reply the suggested changes to make
| hashing possible/easier...)
Did you consider that in your new analysis? If yes, how?
No, but I just checked: among the newest 25 packages in browse.dgit.d.o,
16 contain a d/
On 21.06.24 17:14, Ansgar 🙀 wrote:
And that will remain the case: even with tag2upload the maintainer will
sign some data that was generated and signed on a random machine with
random and possibly-malevolent software that could have silently
replaced any file it wanted to...
The keyword here is
Ansgar 🙀 writes:
> On Fri, 2024-06-21 at 08:29 -0700, Russ Allbery wrote:
>> Wait, why would I ever want to upload a 3.0 (native) package for a
>> non-native package with the tooling as it is today in Debian?
> As far as I understand this whole thread is about changing the tooling.
This whole t
Ansgar 🙀 writes:
> On Fri, 2024-06-21 at 16:55 +0200, Matthias Urlichs wrote:
>> Umm, no. We're not dropping the check; we required a maintainer's
>> signature before, and we still do so after. We just place a
>> packaging-and-possibly-source-mangling server between A and B.
> So we drop the int
Ansgar 🙀 writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> If we are talking about hypothetical ways upstream might nudge you
> into:
No, that's not what Phil's talking about.
Phil's talking about, for example, Russ's git-debrebase workflow,
where the git is treesame to the source p
Hi,
On Fri, 2024-06-21 at 17:24 +0200, Matthias Urlichs wrote:
> On 21.06.24 16:57, Ansgar 🙀 wrote:
> > So your suggested method of measurement and the resulting 80% seem
> > very
> > questionable and only usable as a very generous upper boundary.
>
> You're right but AFAICT this can only happen
Hi,
On Fri, 2024-06-21 at 08:29 -0700, Russ Allbery wrote:
> Ansgar 🙀 writes:
> > And you do not have a working tree containing either the patched source
> > that would allow computing a integrity hash using 3.0 (native) or
> > separate debian/patches where 3.0 (quilt) would work?
>
> Wait, why
On 21.06.24 16:57, Ansgar 🙀 wrote:
So your suggested method of measurement and the resulting 80% seem very
questionable and only usable as a very generous upper boundary.
You're right but AFAICT this can only happen when the two tags are
consecutive, I spot-checked a couple of them to verify t
Ansgar 🙀 writes:
> And you do not have a working tree containing either the patched source
> that would allow computing a integrity hash using 3.0 (native) or
> separate debian/patches where 3.0 (quilt) would work?
Wait, why would I ever want to upload a 3.0 (native) package for a
non-native pac
Hi,
On Fri, 2024-06-21 at 16:55 +0200, Matthias Urlichs wrote:
> On 21.06.24 14:33, Ansgar 🙀 wrote:
> > > IMHO tag2upload does not drop integrity checks, for the simple reason
> > > that a maintainer who uses dgit today does not perform any such test.
> > The change request is for the archive to d
On 21.06.24 14:33, Ansgar 🙀 wrote:
IMHO tag2upload does not drop integrity checks, for the simple reason
that a maintainer who uses dgit today does not perform any such test.
The change request is for the archive to drop them.
Umm, no. We're not dropping the check; we required a maintainer's
Hi,
On Fri, 2024-06-21 at 15:58 +0200, Matthias Urlichs wrote:
> On 21.06.24 14:33, Ansgar 🙀 wrote:
> > I think you misunderstand my question: I would like to know which
> > packages*could not*Â provide an integrity hash for the archive.
>
> Ah, sorry.
>
> Answer: Lots of them. AFAIK you can sim
On 21.06.24 14:33, Ansgar 🙀 wrote:
I think you misunderstand my question: I would like to know which
packages*could not* provide an integrity hash for the archive.
Ah, sorry.
Answer: Lots of them. AFAIK you can simply click on a package in
https://browse.dgit.debian.org/ and check whether th
Hi,
On Fri, 2024-06-21 at 13:55 +0200, Matthias Urlichs wrote:
> On 21.06.24 13:18, Ansgar 🙀 wrote:
> > If we want to drop integrity checks,
>
> IMHO tag2upload does not drop integrity checks, for the simple reason
> that a maintainer who uses dgit today does not perform any such test.
The chang
On 21.06.24 13:18, Ansgar 🙀 wrote:
If we want to drop integrity checks,
IMHO tag2upload does not drop integrity checks, for the simple reason
that a maintainer who uses dgit today does not perform any such test.
"dgit push-source succeeds? fine, I'm done until the buildds report
success (or
On Thu, 2024-06-20 at 12:48 -0700, Russ Allbery wrote:
> Ansgar 🙀 writes:
>
> > Let us talk about *today*. How many packages would not be possible to
> > upload via tag2upload if one required a signature covering content of
> > packages? Is it 0.1%? Is it 90%?
[...]
> I personally do not have
Hi,
On Thu, 2024-06-20 at 08:19 +0200, Philip Hands wrote:
> Similarly, if one has a package that could be dealt with by a limited
> tag2upload, and then upstream changed something that nudged you into the
> problematic territory, you'll be confronted with having to abandon
> tag2upload, or perhap
Andrey Rakhmatullin writes ("Re: What is the source code (was: [RFC] General
Resolution to deploy tag2upload)"):
> On Thu, Jun 20, 2024 at 11:17:42AM -0400, Paul R. Tagliamonte wrote:
> > Is uploading an NMU by dgetting the .dsc, modifying it, and dputing the
> > changed source polite these days?
Paul R. Tagliamonte writes ("Re: What is the source code (was: [RFC] General
Resolution to deploy tag2upload)"):
> If we (as a project) truly regard a .dsc/source distribution as an
> unfortunate intermediate build artifact that we wish to offload to a
> source buildd network, I have to wonder why
29 matches
Mail list logo
