On 17.06.24 07:40, Louis-Philippe Véronneau wrote:
Please excuse my naiveté, but how do you actually know that your
package "works" with the tag2upload workflow if you're not building
anything locally before pushing?
When I change the Upstream sources without touching the packaging
(security
On Mon, Jun 17, 2024 at 07:00:19AM +0200, Bastian Blank wrote:
> But maybe you can answer the question: Given the .dsc file, how can
> you, and more critical the public, verify that you and only you signed
> that upload?
I'm surprised to learn that people check .dsc signatures, especially
as we d
Russ Allbery writes:
> Scott Kitterman writes:
>
>> I agree that there's a risk that what the uploader thought they were
>> uploading and what they actually uploaded are different, but that's
>> independent of tag2upload or not.
>
> But it's not independent; tag2upload makes this story somewhat
Daniel Gröber writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Hi Ansgar,
>
> On Fri, Jun 14, 2024 at 10:39:11PM +0200, Ansgar 🙀 wrote:
> > ...
>
> Could you please expand on this and/or provide references? I have no idea
> what you're even talking about here.
FTR, I have no idea
On 17263 March 1977, Matthias Urlichs wrote:
Still, we should find a way to keep the existing property of
verifying
what the uploader signed to upload *without* requiring a third-party
$something to be available.
Verifying what the uploader signed is simple enough, it's a git tag.
You
fetch
Soren Stoutner writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> 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 Whitto
On Jun 17, Sven Mueller wrote:
>1) because it is the job of FTPmaster to authenticate and authorize the
>uploader (and Joerg sees that as "human uploader", which I somewhat agree
>with)
If this were the actual issue then the ftpmasters could just run the
tag2upload server themselves
Russ Allbery writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Timo Röhling writes:
> > Would it be possible for tag2upload generate some sort of log or diff of
> > its operation? Then, a verifier does not have to reimplement the whole
> > dgit logic with all its edge cases, it merel
Not having fully read everything, would this be acceptable:
- The DSC contains a copy of the original signature, and the hash that was
signed. Possibly an url to the repo at that time.
- there exists some tool that can extract the information from the DSC, verify
the git signature, and that it
Russ Allbery writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> My understanding is that the problem with this
> design from their perspective is that it requires a fat client on the
> uploader's system,
Yes.
Indeed, we have a system very like this already. It's called dgit.
dgit p
Simon Josefsson writes:
> Successfully attacking ALL individual developers, with each own
> individual security weaknesses, seems to me more costly than attacking a
> single known publicly run instance like tag2upload or Salsa.
You only need to be able to sucessfully attack *one* developer in or
Matthias Urlichs writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Another way of doing this would be to teach t2u to simply push the tag
> to an append-only git store.
tag2upload already does precisely that. (dgit does this too.)
> Then teach the builders that instead of their eq
On Sun, 16 Jun 2024 at 19:00, Scott Kitterman wrote:
> I can see that, but that leads to what I view as a problem. The thing in the
> archive is signed by a machine, not the human who decided it should be
> uploaded.
That is nothing new or particularly controversial for Debian Archive.
Nowadays
Joerg Jaspert writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On 17262 March 1977, Sean Whitton wrote:
> > I would ask you not to characterise the disagreement we are having as
> > merely over a technical detail.
>
> You see this as personal? I don't, but if it is not technical, wh
On 17.06.24 10:51, Simon Josefsson wrote:
Successfully attacking ALL individual developers, with each own
individual security weaknesses, seems to me more costly than attacking a
single known publicly run instance like tag2upload or Salsa.
The thing is, you don't need to hack ALL of them to suc
Salvo Tomaselli writes ("Re: How is the original tarball obtained in
tag2upload"):
> I think you [Matthias] assume that 100% of the software is identical
> to the things you work on. Which is probably untrue.
Nevertheless, what Matthias says is true for more and more packages.
*For those packages
Gunnar Wolf writes ("Eternally paradigmatic Debian discussions..."):
> 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 rea
Holger Levsen writes ("Re: Eternally paradigmatic Debian discussions..."):
> I oppose to vote to implement a design proposal.
It's not just a design proposal. The vast majority is already
implemented.
> I also oppose to force certain work on volunteers.
No work is being forced on volunteers.
W
Hi Joerg,
On Mon, Jun 17, 2024 at 12:04:20AM +0200, Joerg Jaspert wrote:
> Also, currently we have the nicety that we store all signatures directly
> besides the source package, available for everyone to go and check.
> Linking back to the actual Uploader, not to a random service key. You
> can ta
Russ Allbery writes ("Re: Security review of tag2upload"):
> I think it would be hugely valuable to have something like a "dgit
> verification mode" where you can ask dgit, which already has all the
> source package construction logic, to take a tag2uplod-generated source
> package, start from the
Brian May writes:
> Simon Josefsson writes:
>
>> Successfully attacking ALL individual developers, with each own
>> individual security weaknesses, seems to me more costly than attacking a
>> single known publicly run instance like tag2upload or Salsa.
>
> You only need to be able to sucessfully
On 17.06.24 12:14, Ian Jackson wrote:
[1] "precisely the patches in d/patches" turns out to be extremely
complicated in the general case. Different maintainer tooling
interprets d/patches differently. dpkg-source and gbp do not agree!
There are maintainer workflows and git trees with partially
Russ Allbery writes ("Re: Security review of tag2upload"):
> [...] in the general case we have absolutely no idea how to
> map a source package in the archive back to a Git tree. That's exactly
> the problem that tag2upload is trying to solve. For non-tag2upload
> packages, we still have to rely
Hi Ian
On 2024/06/17 12:56, Ian Jackson wrote:
* We made fairly formal appeals to two sitting DPLs. What we got
was, basically, attempts at mediation, or facilitation of
discussions. We didn't see that as helpful, since we saw an
irreconcilable gap between our position and ftpmas
Am 2024-06-17 11:39, schrieb Joerg Jaspert:
On 17263 March 1977, Matthias Urlichs wrote:
Still, we should find a way to keep the existing property of
verifying
what the uploader signed to upload *without* requiring a third-party
$something to be available.
Verifying what the uploader signed is
Matthias Urlichs writes ("Re: [RFC] General Resolution to deploy tag2upload
[and 1 more messages]"):
> Say I need to apply a security patch to some package's git tree on
> Salsa. How can I be sure to even create the same source tree as the
> previous uploader? I don't know which tool the maintai
Quoting Matthias Urlichs (2024-06-17 13:05:17)
> On 17.06.24 12:14, Ian Jackson wrote:
> > [1] "precisely the patches in d/patches" turns out to be extremely
> > complicated in the general case. Different maintainer tooling
> > interprets d/patches differently. dpkg-source and gbp do not agree!
>
Kurt Roeckx writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> [how about a design which includes:]
>
> - there exists some tool that can extract the information >from the
> DSC, verify the git signature, and that it generates a tar with
> the same content?
The difficult part is "
On Fri, Jun 14, 2024 at 02:35:24PM -0700, Russ Allbery wrote:
> Phil Morrell writes:
>
> > It's been my impression [citation needed] that pristine-tar/lfs still
> > exists mainly out of inertia and simple tooling around it that makes it
> > more of a why not. If we're gaining a mostly git-native
Jonas Smedegaard writes ("Re: [RFC] General Resolution to deploy tag2upload
[and 1 more messages]"):
> Your WTF seems to be from a false assumption that git is central to
> Debian package maintenance. It isn't. It is popular, but not central,
> nor standardized.
git is central to most software m
On Mon, Jun 17, 2024, 04:53 Jonas Smedegaard wrote:
> Quoting Matthias Urlichs (2024-06-17 13:05:17)
> > [...]
> > Thus I need to ignore the maintainer's git tree in favor of "apt-get
> > source", manually apply the fix, upload that to the archive, then apply
> > the (hopefully) exact same patch
On Mon, Jun 17, 2024 at 05:07:43AM -0700, Michael Lustfield wrote:
> > > Thus I need to ignore the maintainer's git tree in favor of "apt-get
> > > source", manually apply the fix, upload that to the archive, then apply
> > > the (hopefully) exact same patch to the actual git sources. Sorry but
> >
On Sun, 16 Jun 2024 at 17:32, Bart Martens wrote:
>
> On Sun, Jun 16, 2024 at 03:31:25PM +0200, Matthias Urlichs wrote:
> > On 13.06.24 10:26, Sean Whitton wrote:
> > > Yes. A proposal that has not yet engaged with the complexities of
> > > 3.0 (quilt) is not one in which we can yet have any conf
Michael Lustfield writes ("Re: [RFC] General Resolution to deploy tag2upload
[and 1 more messages]"):
> Is this a GR?
It is not yet a formally proposed GR. So in one sense, no.
> If it is, don't we have a process that's designed to eventually
> stop never-ending back and forth disagreements, li
Quoting Ian Jackson (2024-06-17 14:13:00)
> Jonas Smedegaard writes ("Re: [RFC] General Resolution to deploy tag2upload
> [and 1 more messages]"):
> > Your WTF seems to be from a false assumption that git is central to
> > Debian package maintenance. It isn't. It is popular, but not central,
> >
On 17.06.24 13:53, Jonas Smedegaard wrote:
What you "need to" do, if you want to contribute to a Debian package, is
follow whatever is the maintenance style for that package.
Exactly. The problem is that, *assuming* that the maintainer uses git,
which IMHO the majority does, I *still* have no
Hi,
On Mon, 2024-06-17 at 08:30 +0200, Matthias Urlichs wrote:
> On 17.06.24 00:04, Joerg Jaspert wrote:
> > Still, we should find a way to keep the existing property of verifying
> > what the uploader signed to upload *without* requiring a third-party
> > $something to be available.
>
> Verifyi
On 17 Jun 2024, at 14:53, Ansgar 🙀 wrote:
>
> Hi,
>
> On Mon, 2024-06-17 at 08:30 +0200, Matthias Urlichs wrote:
>> On 17.06.24 00:04, Joerg Jaspert wrote:
>>> Still, we should find a way to keep the existing property of verifying
>>> what the uploader signed to upload *without* requiring a thir
Hi,
On 6/17/24 20:38, Jonathan Carter wrote:
When it comes to tag2upload, I believe it's something that most people
would want. At least it doesn't take away from any existing workflow or
force people to change their habits right away, so in terms of being
able to gain support for it, it has
On June 17, 2024 10:56:11 AM UTC, Ian Jackson
wrote:
>Joerg Jaspert writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>> On 17262 March 1977, Sean Whitton wrote:
>> > I would ask you not to characterise the disagreement we are having as
>> > merely over a technical detail.
>>
>> Y
A few more weeks, eh?
To me, it seems like we're intentionally avoiding the GR process because we
don't like the process and have decided to simply ignore it for the sake of
extending the discussion.
On Mon, Jun 17, 2024, 06:04 Ian Jackson
wrote:
> Michael Lustfield writes ("Re: [RFC] General R
On Mon, Jun 17, 2024 at 07:50:30AM -0700, Michael Lustfield wrote:
> A few more weeks, eh?
>
> To me, it seems like we're intentionally avoiding the GR process because we
> don't like the process and have decided to simply ignore it for the sake of
> extending the discussion.
Which is a GR author
> A few more weeks, eh?
>
> To me, it seems like we're intentionally avoiding the GR process because we
> don't like the process and have decided to simply ignore it for the sake of
> extending the discussion.
Technically, the GR process advantages the ones proposing a GR
for giving them more tim
Simon Josefsson writes:
> Russ Allbery writes:
>> But it's not independent; tag2upload makes this story somewhat better.
>> tag2upload is based on a signed Git tag and moves the source package
>> construction off of the uploader's system onto more-secure project
>> infrastructure.
> I've seen t
Louis-Philippe Véronneau writes:
> On 2024-06-16 2 h 23 p.m., Russ Allbery wrote:
>> For the existing source package signatures, a simplified sequence looks
>> like this:
>> human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive
>> For tag2upload, a simplified sequence looks like:
>>
Simon Richter writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On 6/17/24 20:38, Jonathan Carter wrote:
> > When it comes to tag2upload, I believe it's something that most people
> > would want. At least it doesn't take away from any existing workflow or
> > force people to change
Scott Kitterman writes:
> I think if you want to step away from the implementation details, the
> more abstract point is that you don't need data from outside the archive
> (or a mirror of the archive) in order to verify that the source package
> you downloaded has not been modified since then an
Hi,
On 6/17/24 18:49, Marco d'Itri wrote:
There is another aspect he mentioned: he thinks the uploader needs to test
the build of the package. (I'm theory I agree, but there are situations
Everybody can upload totally untested packages even without tag2upload:
maybe tag2upload would
On Mon, Jun 17, 2024, 08:18 Judit Foglszinger wrote:
> > A few more weeks, eh?
> >
> > To me, it seems like we're intentionally avoiding the GR process because
> we
> > don't like the process and have decided to simply ignore it for the sake
> of
> > extending the discussion.
>
> Technically, the
Michael Lustfield writes:
> To me, it seems like we're intentionally avoiding the GR process because
> we don't like the process and have decided to simply ignore it for the
> sake of extending the discussion.
I'm the person who wrote the current timelines that the GR process
follows. I complet
Jonas Smedegaard writes ("Re: [RFC] General Resolution to deploy tag2upload
[and 1 more messages]"):
> Quoting Ian Jackson (2024-06-17 14:13:00)
> > git is central to most software maintenance in the world at large.
> > Not all, by any means. But, overwhelmingly, most.
> >
> > In Debian it's uns
Hi,
On Mon, 2024-06-17 at 14:59 +0100, Jessica Clarke wrote:
> On 17 Jun 2024, at 14:53, Ansgar 🙀 wrote:
> > It essentially introduces an alternative authentication system (and
> > authorization system as tag2upload seems to care about DM status) that
> > *replaces* the one in dak *and* *disagree
Thanks, Joerg and Ian, for summing it up in this subthread and
arriving at the mail I am quoting. I think that, if we are to vote on
this topic, both sides to this disagreement should be made clear and
explicit. The call for votes should include, or at least prominently
link to, where the disagreem
Hi,
On 6/17/24 21:13, Ian Jackson wrote:
Your WTF seems to be from a false assumption that git is central to
Debian package maintenance. It isn't. It is popular, but not central,
nor standardized.
git is central to most software maintenance in the world at large.
Not all, by any means. But
Gunnar Wolf writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Thanks, Joerg and Ian, for summing it up in this subthread and
> arriving at the mail I am quoting. I think that, if we are to vote on
> this topic, both sides to this disagreement should be made clear and
> explicit. The c
On 17.06.24 17:50, Simon Richter wrote:
marketed to us not on its technical merits, but on how it will allow
us to take shortcuts
I wouldn't call what tag2upload does a "shortcut". Current workflows
(i.e. without tag2upload) do not contain any steps that t2u would skip.
t2u simply does these
So, first, I owe you and the FTP team an apology. I was totally convinced
that there had been more recent public discussions of tag2upload involving
the FTP team than 2019. I either got confused with other discussions or
had the increasingly common problem of thinking that things that happened
te
On 17.06.24 19:50, Simon Richter wrote:
They all fall short, because git cannot represent the data model of
Debian source packages
Well. I wouldn't go that far. A Debian source package, after all, is
simply a directory tree with a bunch of files in a debian/ subdirectory.
There's nothing magi
Simon Richter writes ("Re: [RFC] General Resolution to deploy tag2upload [and 1
more messages]"):
> I think we cannot increment ourselves into a good solution here.
We certainly can improve things a long way. That's what we're doing.
The way to do a big transition is to write a gateway, and then
On Mon, 17 Jun 2024, 18:50 Simon Richter, wrote:
> Hi,
>
> On 6/17/24 18:49, Marco d'Itri wrote:
>
> >> There is another aspect he mentioned: he thinks the uploader needs
> to test
> >> the build of the package. (I'm theory I agree, but there are
> situations
>
> > Everybody can upload to
Russ Allbery writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Joerg Jaspert writes:
> > I also do assume that the uploader will build things, to see if the
> > stuff they are going to "push to the archive" (and our users) actually
> > does what they intended it to do - and to test i
Sent from Workspace ONE Boxer
On Jun 17, 2024 6:23 PM, Ansgar 🙀 wrote:
>
> Hi,
>
> On Mon, 2024-06-17 at 14:59 +0100, Jessica Clarke wrote:
> > On 17 Jun 2024, at 14:53, Ansgar 🙀 wrote:
> > > It essentially introduces an alternative authentication system (and
> > > authorization sys
On 17263 March 1977, Ian Jackson wrote:
Which behind the scenes? To who did you talk?
Firstly, I want to ask: would it have made any difference if we had
raised the matter in public again on -devel?
Or if you would directly have addressed us. That happened last in 2019.
And Sean is part of th
If you have a source package already compiled locally to be
manifested/signed, then why are you not just uploading that? This
assumption completely removes the point of tag2upload.
There are plenty of valid use cases that do not create a dsc locally. Or
wouldn't if it wasn't required for upload.
Hi there ! o/
On Jun 17, 2024 11:11 PM, Aigars Mahinovs wrote:
>
> If you have a source package already compiled locally to be
> manifested/signed, then why are you not just uploading that? This assumption
> completely removes the point of tag2upload.
Well... I see no point in tag2upload a
On Jun 17, 2024 8:57 PM, Russ Allbery wrote:
> What signed artifact do I need to provide so that the FTP team will be
> comfortable accepting my tag2upload-built source package?
Signed .dsc and .changes files should be fine ... ;)
> Note, importantly, that the source package contains thin
66 matches
Mail list logo
