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
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
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
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
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
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
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
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.
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
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
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,
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
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
>>>
> "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
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
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
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
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.
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
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
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.
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
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
>
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
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
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
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
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
* 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
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
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
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
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
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.
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
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
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
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 …?
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
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,
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
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 -->
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
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
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 -->
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
>
46 matches
Mail list logo
