Scott Kitterman writes:
> Today I can download any source package in the archive and verify who
> uploaded the package and is responsible for its contents. It doesn't
> matter if I download it from the main archive or a mirror. Personally,
> I think that's an important characteristic of our pac
Russ Allbery dijo [Sat, Jun 15, 2024 at 11:44:35PM -0700]:
> A tag2upload server compromise is fairly serious. A compromise of any of
> tag2upload, dak, or the buildds have roughly equally serious potential
> impact on the archive as far as I can tell, although the details differ.
> In all three c
Scott Kitterman writes:
> I appreciate the thought and effort that went into this review.
> If I'm following your description correctly, the tag2upload "package" flow is:
> developer --> salsa --> tag2upload --> ftp.upload.debian.org
> machine --> d
Russ Allbery dijo [Fri, Jun 14, 2024 at 02:06:35PM -0700]:
> (...)
> The tag2upload developers have been working on this system for many years
> now. Deployment has been blocked by an FTP team decision. At this point,
> the tag2upload developers are quite understandably not willing to do more
> w
On June 16, 2024 4:38:03 AM UTC, Sean Whitton wrote:
>Hello,
>
>On Fri 14 Jun 2024 at 06:06pm GMT, Scott Kitterman wrote:
>
>>
>> I'm a bit confused by the claim that no infrastructure changes are needed for
>> this to go forward.
>>
>> If I have been following the proposal correctly, source pa
Hello,
On Sat 15 Jun 2024 at 11:12am +02, Jonathan Carter wrote:
> Hi Sean
>
> On 2024/06/15 02:14, Sean Whitton wrote:
>> My point is that it's not doing any magic. It's less than 500 lines of
>> shell.
>
> Where do I find this? I searched for tag2upload on salsa and did an 'apt-cache
> search
Hello,
On Fri 14 Jun 2024 at 06:06pm GMT, Scott Kitterman wrote:
>
> I'm a bit confused by the claim that no infrastructure changes are needed for
> this to go forward.
>
> If I have been following the proposal correctly, source packages will be
> signed by tag2upload and not the uploader. Doesn
Hello,
On Fri 14 Jun 2024 at 11:44pm -06, Gunnar Wolf wrote:
>
>In any case... I understand you want to give some "discussion time"
>before pushing the process. But, is there something in particular
>you are waiting from this discussion?
>
Ian and I are going through the thread and w
Hello,
On Sat 15 Jun 2024 at 07:12pm +02, Sven Mueller wrote:
> I'm currently a bystander. And while I reply to Joerg's mail, I'm not
> directly referencing
> any of the points in his mail, so no quotes.
>
> I'd like to point out though, that signing the content of the package is not
> possible
Hello,
On Sat 15 Jun 2024 at 06:03pm +02, Joerg Jaspert wrote:
> On 17258 March 1977, Sean Whitton wrote:
>
>> So, why am I proposing a GR?
>
> This one took me by surprise, honestly.
>
> Looking into my notmuch, the last time tag2upload came up in my
> ftpmaster inbox was in 2019. Between then a
On Tuesday, June 11, 2024 9:39:04 PM EDT Russ Allbery wrote:
> Hi all,
>
> Below is the security review that I did of the tag2upload design.
>
> I am not a neutral party, in the sense that I think tag2upload is a good
> idea and should be deployed. However, I do these types of security
> reviews
On Jun 15, Russ Allbery wrote:
> The serialization isn't the problem, constructing the source package is.
> Once you have a source package, there are lots of things you can do, but
> the problem is precisely that going from a Git tree to a source package is
> non-trivial and involves a whole bunc
Marco d'Itri writes:
> r...@debian.org wrote:
>> My understanding is that the problem with this design from their
>> perspective is that it requires a fat client on the uploader's system,
>> and whole point of tag2upload is to stop requiring a fat client on the
>> uploader's system. In particula
r...@debian.org wrote:
>My understanding is that the problem with this
>design from their perspective is that it requires a fat client on the
>uploader's system, and whole point of tag2upload is to stop requiring a
>fat client on the uploader's system. In particular, it requires all the
>code to
Thank you for writing this up. This is extremely helpful to make clear
what the actual point of contention is.
Joerg Jaspert writes:
> FTPMaster *is* in support of t2u, if it ends up in a way that allows dak
> doing the final verification/authorization of the upload, NOT needing to
> trust some
I'm currently a bystander. And while I reply to Joerg's mail, I'm not directly referencing any of the points in his mail, so no quotes.I'd like to point out though, that signing the content of the package is not possible if the developer should only need to do `git $something`.They would also need
On 6/15/24 11:16, Holger Levsen wrote:
On Fri, Jun 14, 2024 at 11:44:04PM -0600, Gunnar Wolf wrote:
1. Nobody really opposes what is being proposed.
I oppose to vote to implement a design proposal. I also oppose to force
certain work on volunteers.
+1
Cheers,
Thomas Goirand (zigo)
Bart Martens writes:
> On Wed, Jun 12, 2024 at 06:25:02AM +0800, Sean Whitton wrote:
>> BEGIN FORMAL RESOLUTION TEXT
>>
>> tag2upload allows DDs and DMs to upload simply by using the
>> git-debpush(1) script to push a signed git tag.
> Question. Does the tag signer need to trust the remote vcs
On 17261 March 1977, Gunnar Wolf wrote:
1. Nobody really opposes what is being proposed.
The opposition is against technical details and the refusal to adjust.
Not against the actual thing.
4. I understand Sean (and Ian, I pressume) are pushing this GR to
solve a stalemate while negotiati
On 17258 March 1977, Sean Whitton wrote:
So, why am I proposing a GR?
This one took me by surprise, honestly.
Looking into my notmuch, the last time tag2upload came up in my
ftpmaster inbox was in 2019. Between then and now there doesn't appear
to
be any serious contact with us about it. Th
Hi Sean,
On Wed, Jun 12, 2024 at 06:25:02AM +0800, Sean Whitton wrote:
> BEGIN FORMAL RESOLUTION TEXT
>
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.
Question. Does the tag signer need to trust the remote vcs and its admins at
the
Hi Ansgar,
On Fri, Jun 14, 2024 at 10:39:11PM +0200, Ansgar 🙀 wrote:
> (And given upstream's hard policy to not merge changes not signing off
> extra legal stuff, I sadly cannot give a more detailed bug report as
> any fix created as a derived work from that would be unmergable unless
> there was
On Fri, Jun 14, 2024 at 11:44:04PM -0600, Gunnar Wolf wrote:
> 1. Nobody really opposes what is being proposed.
I oppose to vote to implement a design proposal. I also oppose to force
certain work on volunteers. This is very similar to voting to publish
-private.
I didnt have time to even read th
Hi Sean
On 2024/06/15 02:14, Sean Whitton wrote:
My point is that it's not doing any magic. It's less than 500 lines of shell.
Where do I find this? I searched for tag2upload on salsa and did an
'apt-cache search tag2upload', but couldn't find anything.
thanks,
-Jonathan
Sean Whitton writes:
...
> The ftpmaster team have refused to trust uploads coming from the
> tag2upload service. This GR is to override that decision.
Full disclosure:
I'm a happy dgit user. The support I've had from Ian for dgit (when I
messed things up, generally) has been outstandingly
Quoting Gunnar Wolf (2024-06-15 07:44:04)
> It seems Sean's GR (pre-)proposal perfectly fits the bill for most
> paradigmatic Debian discussions. From (half-)following the discussion,
> (must confess I have >80 pending messages I haven't read, so there
> might be some reality check I haven't yet ap
As someone who has read every email in this chain, I have a couple of
recommendations.
1. Clarify that the GR does not prevent future flexibility in changing the
tag2upload service
and does not give Sean Whitton, Ian Jackson, Jonathan McDowell, or Russ Allbery
perpetual
power to direct how i
Phil Morrell writes:
> On Fri, Jun 14, 2024 at 12:26:50PM +0100, Ian Jackson wrote:
>> Andreas Tille writes ("How is the original tarball obtained in tag2upload"):
>> > In many teams we keep the metadata about the
>> > orig.tar.$COMPRESSION tarball in pristine-tar branch. In most cases
>> > this
28 matches
Mail list logo
