Re: Security review of tag2upload

2024-06-16 Thread Scott Kitterman
On June 17, 2024 5:29:02 AM UTC, Russ Allbery wrote: >Scott Kitterman writes: > >> I don't equate responsibility and blame. If I'm responsible for >> something and it blows up, then that means I'm responsible to help clean >> up the mess, regardless of if the thing that went wrong is my

Re: Security review of tag2upload

2024-06-16 Thread Louis-Philippe Véronneau
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: human --> (1) Git --> (2) tag2upload

Re: A thought experiment regarding tag2upload and trust

2024-06-16 Thread Scott Kitterman
On June 17, 2024 5:23:41 AM UTC, Russ Allbery wrote: >Bastian Blank writes: > >> 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? > >Why is this, specifically, important? > >I can

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
Scott Kitterman writes: > I don't equate responsibility and blame. If I'm responsible for > something and it blows up, then that means I'm responsible to help clean > up the mess, regardless of if the thing that went wrong is my fault or > not. How is that type of responsibility not correctly

Re: A thought experiment regarding tag2upload and trust

2024-06-16 Thread Russ Allbery
Bastian Blank writes: > 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? Why is this, specifically, important? I can turn that question around: given the .dsc file, how can I find the

Re: A thought experiment regarding tag2upload and trust

2024-06-16 Thread Bastian Blank
Hi On Sat, Jun 15, 2024 at 11:03:17AM +0200, Philip Hands wrote: > If Ian were to offer a hosting service for such personal tag2upload > instances, in a way that he assured me could not be used to sign > packages unless I had signed a matching git-tag, I would be willing to > trust his

Re: A thought experiment regarding tag2upload and trust

2024-06-16 Thread Louis-Philippe Véronneau
On 2024-06-17 12 h 47 a.m., Scott Kitterman wrote: On Monday, June 17, 2024 12:25:28 AM EDT Louis-Philippe Véronneau wrote: On 2024-06-15 5 h 03 a.m., Philip Hands wrote: Sean Whitton writes: ... The ftpmaster team have refused to trust uploads coming from the tag2upload service. This GR

Re: A thought experiment regarding tag2upload and trust

2024-06-16 Thread Scott Kitterman
On Monday, June 17, 2024 12:25:28 AM EDT Louis-Philippe Véronneau wrote: > On 2024-06-15 5 h 03 a.m., Philip Hands wrote: > > > Sean Whitton writes: > > ... > > > >> The ftpmaster team have refused to trust uploads coming from the > >> tag2upload service. This GR is to override that decision.

Re: Security review of tag2upload

2024-06-16 Thread Scott Kitterman
On Sunday, June 16, 2024 3:59:40 PM EDT Russ Allbery wrote: > Scott Kitterman writes: > > Yes. I think that's the core of the disagreement. In my view, when I > > type the passphrase for my key, I'm asserting responsibility for the > > contents of what I'm signing. It doesn't mean it is

Re: A thought experiment regarding tag2upload and trust

2024-06-16 Thread Louis-Philippe Véronneau
On 2024-06-15 5 h 03 a.m., Philip Hands wrote: 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

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Marco d'Itri
jo...@debian.org wrote: >We want dak (and anyone else) to be able to say "Yes, DD/DM $x has >signed off this content". That only works, if dak (and later, the >public, if they want to check too) have the signature for this in a way >they can verify it. And not just a line somewhere "Sure,

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Joerg Jaspert
On 17261 March 1977, Russ Allbery wrote: 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 other instance. Why is this your red line? Is it only that you don't want to add another

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Philip Hands
Russ Allbery writes: > 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 >>>

Re: Security review of tag2upload

2024-06-16 Thread Sam Hartman
> "Russ" == Russ Allbery writes: >> 2) Attacker possibly through a compromise of the dgit server and >> salsa changes the git view to be something harmless. Sorry I was assuming that the web ui and the git repository were still consistent, but were inconsistent with what was

Re: How is the original tarball obtained in tag2upload

2024-06-16 Thread Matthias Urlichs
On 15.06.24 09:03, Simon Josefsson wrote: As far as I can tell, tag2upload will make reproducible source artifacts harder to achieve (git-archive is run as a SaaS, and may not match what upstream publish) and verify (any PGP signatures from upstream on the git-archive is thrown away), but in

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Joerg Jaspert
On 17262 March 1977, Sean Whitton wrote: 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. There had been mentionings on some mailing list somewhere, but nothing

Re: Security review of tag2upload

2024-06-16 Thread Sven Mueller
Am 16.06.2024 21:11 schrieb Scott Kitterman : Yes.  I think that's the core of the disagreement.  In my view, when I type the passphrase for my key, I'm asserting responsibility for the contents of what I'm signing.  It doesn't mean it is correct or uncompromised, but I am taking responsibility

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
Scott Kitterman writes: > Yes. I think that's the core of the disagreement. In my view, when I > type the passphrase for my key, I'm asserting responsibility for the > contents of what I'm signing. It doesn't mean it is correct or > uncompromised, but I am taking responsibility for it.

Re: Security review of tag2upload

2024-06-16 Thread Matthias Urlichs
On 16.06.24 21:11, Scott Kitterman wrote: Yes. I think that's the core of the disagreement. In my view, when I type the passphrase for my key, I'm asserting responsibility for the contents of what I'm signing. Right. But in both cases what you're signing is a random hash consisting of bits

Re: Archive support for *.orig.bundle.* and *.debian.bundle.*

2024-06-16 Thread Adam D. Barratt
On Sun, 2024-06-16 at 20:40 +0200, Matthias Urlichs wrote: > Do we delete all our old snapshots from snapshot.d.o if/when > infringing or non-Free content is detected in a package? >  AFAIK: no we don't. Access to packages on snapshot.d.o has been blocked several times in the past due to issues

Re: Security review of tag2upload

2024-06-16 Thread Scott Kitterman
On June 16, 2024 6:23:18 PM UTC, Russ Allbery wrote: >Scott Kitterman writes: > >> I think it's just that I view a signature by a mechanized service as >> something different that a signature made by an actual person. >> Technically you are correct, but I think it's fundamentally different.

Re: Archive support for *.orig.bundle.* and *.debian.bundle.*

2024-06-16 Thread Matthias Urlichs
On 14.06.24 11:38, Simon McVittie wrote: With the whole git history as a bundle, and our current policies around Freeness, the maintainer and the ftp team would be responsible for ensuring and verifying that every past commit reachable from the bundle is*also* Free, which is a much, much larger

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Gunnar Wolf
Matthias Urlichs dijo [Sun, Jun 16, 2024 at 04:28:29PM +0200]: > On 13.06.24 21:51, Gunnar Wolf wrote: > > But there can be many reasons the > > three of us (keyring-maints) are unreachable for several hours. > > Maybe a "send your key revocation certificate here and this will be done >

Re: [RFC] General Resolution to deploy tag2upload [and 1 more messages]

2024-06-16 Thread Matthias Urlichs
On 13.06.24 13:00, Ian Jackson wrote: it's part of the "preferred form for modification" as the GPL has it. Well, that's a whole 'nother kettle of fish. On one hand I agree with you. Pretty much anything you do to a nontrivial source archive requires access to its history. On the other

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
Scott Kitterman writes: > I think it's just that I view a signature by a mechanized service as > something different that a signature made by an actual person. > Technically you are correct, but I think it's fundamentally different. > I don't think the computer is responsible for anything. I

Re: Security review of tag2upload

2024-06-16 Thread Stefano Rivera
Hi Scott (2024.06.16_16:18:35_+) > There are different risks for the end user. Currently dget uses dscverify by > default before unpacking a source package. I'm not an expert at all, so I > don't have any appreciate for the perceived risks that led to that being the > default (IIRC, it

Re: Security review of tag2upload

2024-06-16 Thread Scott Kitterman
On Sunday, June 16, 2024 12:46:41 PM EDT Russ Allbery wrote: > 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

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
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 better. tag2upload is based on

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Timo Röhling
* Russ Allbery [2024-06-16 09:02]: I believe that's what tag2upload pushes to the dgit-repos server, although I'm not sure that exactly matches what you're asking for. I was pondering over a way to securely link the Git tag with the upload. I think it needs to be a representable as a file that

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
Sam Hartman writes: > You talk a number of times about whether an attack is possible against > salsa. But especially when thinking about detection and tracing, I > think that things that are verified by signatures made with keys not > held by the system in question are harder to modify than

Re: Security review of tag2upload

2024-06-16 Thread Scott Kitterman
On Sunday, June 16, 2024 12:01:31 PM EDT Russ Allbery wrote: > Scott Kitterman writes: > > Yes and no. The difference is that currently, I can download the source > > package and verify it myself. Not just who signed it and with what key, > > but that the signature verifies. I don't need to

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Russ Allbery
Matthias Urlichs writes: > On 15.06.24 00:37, Russ Allbery wrote: >> dak should not be doing the source package transformation, because that >> is a much more complicated process and therefore a larger security >> attack surface. That's why it's done in a sandbox with a bunch of >> privilege

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Russ Allbery
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 merely has to apply the same tree > transformation(s) as t2u and verify that this will

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
Scott Kitterman writes: > Yes and no. The difference is that currently, I can download the source > package and verify it myself. Not just who signed it and with what key, > but that the signature verifies. I don't need to trust assurances from > any service. No, that's not quite true.

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Bart Martens
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 confidence. > > The proposal simply intends to do whatever the

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Scott Kitterman
On Sunday, June 16, 2024 12:26:48 AM EDT Sean Whitton wrote: > 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

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Matthias Urlichs
On 12.06.24 14:18, Ian Jackson wrote: The alternative would be a SHA256 manifest of the git tree. I assume we could just wait another four years. By that time all git tooling should support sha256 natively, all our git trees can be converted to default to using sha256, and so on. I'd also

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Matthias Urlichs
On 13.06.24 21:51, Gunnar Wolf wrote: But there can be many reasons the three of us (keyring-maints) are unreachable for several hours. Maybe a "send your key revocation certificate here and this will be done automagically" emergency-revocation@d.o email address might be a good idea …?

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Matthias Urlichs
On 15.06.24 00:37, Russ Allbery wrote: dak should not be doing the source package transformation, because that is a much more complicated process and therefore a larger security attack surface. That's why it's done in a sandbox with a bunch of privilege separation. … which incidentally is far

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Matthias Urlichs
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 confidence. The proposal simply intends to do whatever the uploader would do to build the source package from a tagged git worktree,

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Timo Röhling
Hi Russ, * Russ Allbery [2024-06-15 23:57]: 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

Re: Security review of tag2upload

2024-06-16 Thread Scott Kitterman
On June 16, 2024 6:44:35 AM UTC, Russ Allbery wrote: >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 -->

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Russ Allbery
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

Re: Security review of tag2upload

2024-06-16 Thread Gunnar Wolf
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

Re: Security review of tag2upload

2024-06-16 Thread Russ Allbery
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 -->

Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Gunnar Wolf
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 >