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.
Verifying what the uploader signed is simple enough, it's a git tag. You
fetch it and
On 15.06.24 11:03, Philip Hands wrote:
If it were easy to deploy an instance of tag2upload in my house,
populated with a sub-key of my GPG key, I would probably set that up
(and then start worrying about the security of the sub-key 😉 ).
If I did that, I believe the FTP masters would still accept
On 16.06.24 23:23, Philip Hands wrote:
We seem to be very focused on how one might reproduce the source
package, to make sure that it can be bit-for-bit generated from the
signed tag, which is clearly a hard thing to do.
Do we actually need to do that at all?
Part of the problem space is to prev
Am 17.06.2024 00:48 schrieb 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
On 2024-06-17 2 h 11 a.m., Jonas Smedegaard wrote:
I rarely call `dpkg-buildpackage -S` directly. Instead I call `debuild`,
or some wrapper around that.
If tag2upload becomes part of Debian, I would expect debuild and/or some
of its wrappers to suppor hooking into tag2upload, for a single comma
Quoting Louis-Philippe Véronneau (2024-06-17 07:40:51)
> 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 tag2uplo
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 fault
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 turn
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 r
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
Git
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 assurances,
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 i
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 correct
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
mes
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, $service
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
sys
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
>>> u
> "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 uploa
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 Didi
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 co
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 for
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.
Right.
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 y
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 wi
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
> automagica
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 hand
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 thi
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 was
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 independen
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 a
* 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 thin
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 tru
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 sep
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. You'r
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 u
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 la
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 li
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 …?
Howe
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, exc
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 tha
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 --> ftp.upload.debi
48 matches
Mail list logo
