On Thu, 2019-08-01 at 16:22:19 +0100, Sean Whitton wrote:
> On Thu 01 Aug 2019 at 02:35PM +02, Guillem Jover wrote:
> > This argument seems very counter-intuitive. This assumes a
> > Debian-archive-centric world-view, where most of the heavy lifting is
> > delegated to some external service. But
Charles Plessy writes:
> if creating a source package is fast and reproducible, could the dgit
> user commit the signed .dsc file somewhere, and the dgit infrastructure
> use it and throw an error if the hash sums do not match ?
A difficulty with using the .dsc file as a signed artifact if you
Hello everybody,
sorry if it is too naive, and sorry if I missed part of the discussion,
but,
if creating a source package is fast and reproducible, could the
dgit user commit the signed .dsc file somewhere, and the dgit
infrastructure use it and throw an error if the hash sums do not match ?
Marco d'Itri writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> On Aug 02, Sam Hartman wrote:
> > In effect, ftpmaster is saying they are uncomfortable trusting
> > tag2upload very much.
>
> A simple solution to this concern woul
On Aug 02, Sam Hartman wrote:
> In effect, ftpmaster is saying they are uncomfortable trusting
> tag2upload very much.
A simple solution to this concern would be for ftpmaster to take over
the operations of tag2upload once it will be ready.
--
ciao,
Marco
signature.asc
Description: PGP
On 02/08/2019 19:09, Ian Jackson wrote:
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
Can you outline how to get from the dsc to a verification of the tag
signature without contacting the dgit server?
Sure.
Split the tag object daa at th
> "Ian" == Ian Jackson writes:
>> Can you outline how to get from the dsc to a verification of the
>> tag signature without contacting the dgit server?
Ian> Sure.
Ian> Split the tag object daa at the relevant - boundary. This
Ian> gives you 1. an unsigned tag data
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> Ian Jackson writes:
> > This requirement can be met (as I mentioned before) by
> > including the tag object data as a file in the upload (listed
> > in .changes). The signat
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: tag2upload (git-debpush) service
Ian> architecture - draft"):
>> Sean Whitton writes: > Okay, thanks.
>>
>> > I think that the Git-Tag-Info field solves this. With that >
>> field available, anyone can do
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> Sean Whitton writes:
> > Okay, thanks.
>
> > I think that the Git-Tag-Info field solves this. With that
> > field available, anyone can do the following to perform an
>
Hello,
On Thu 01 Aug 2019 at 02:35PM +02, Guillem Jover wrote:
> On Thu, 2019-08-01 at 04:37:41 -0700, Sean Whitton wrote:
>> On Wed 31 Jul 2019 at 10:53PM +01, Rebecca N. Palmer wrote:
>> > Do "complicated and inconvenient" mean "harder to remember than 'git
>> > debpush'" (which could equally
Hello,
On Thu 01 Aug 2019 at 09:35AM -04, Sam Hartman wrote:
> This violates the "no external data" requirement above.
>
> You could technically meet this requirement by including a git bundle in
> the dsc, although that would be an unacceptable design for a variety of
> other reasons that seem
> "Sean" == Sean Whitton writes:
Sean> Hello Bastian,
Sean> On Wed 31 Jul 2019 at 10:37PM +02, Bastian Blank wrote:
>> On Wed, Jul 31, 2019 at 03:21:32PM -0400, Sam Hartman wrote:
Bastian> One last time: The user has to certify his upload in a way
Bastian> the archive
On Thu, 2019-08-01 at 04:37:41 -0700, Sean Whitton wrote:
> On Wed 31 Jul 2019 at 10:53PM +01, Rebecca N. Palmer wrote:
> > Do "complicated and inconvenient" mean "harder to remember than 'git
> > debpush'" (which could equally well be fixed by a local-only script),
> > the confusing errors
Hello Bastian,
On Wed 31 Jul 2019 at 10:37PM +02, Bastian Blank wrote:
> On Wed, Jul 31, 2019 at 03:21:32PM -0400, Sam Hartman wrote:
>> Bastian> One last time: The user has to certify his upload in a way
>> Bastian> the archive can verify.
>> Let me see if I'm correctly understanding
Hello,
On Wed 31 Jul 2019 at 10:53PM +01, Rebecca N. Palmer wrote:
> Do "complicated and inconvenient" mean "harder to remember than 'git
> debpush'" (which could equally well be fixed by a local-only script),
> the confusing errors mentioned below, or something else?
It's a qualitative claim
Bastian Blank wrote:
The git object
checksums don't suffice anymore due to SHA1. And as the world moves
towards SHA3, it will need to have the ability to follow.
Ian Jackson wrote:> The git signed tag object has a signature which is
verifiable without
relying on the git object hash system.
On 31/07/2019 17:08, Ian Jackson wrote:
.dsc generation is complicated, slow, and inconvenient.
In what circumstances is it slow enough to matter?
My measurements, in a sid chroot:
source .orig .debian origcreate dpkg-b.
size size time time
dgit(native)4M 0.3sec
Hi Sam
On Wed, Jul 31, 2019 at 03:21:32PM -0400, Sam Hartman wrote:
> Bastian> One last time: The user has to certify his upload in a way
> Bastian> the archive can verify.
> Let me see if I'm correctly understanding this requirement. You're
> saying that given the dsc presented to dak
>>>>> "Bastian" == Bastian Blank writes:
Bastian> Hi Ian
Bastian> On Wed, Jul 31, 2019 at 05:08:51PM +0100, Ian Jackson wrote:
>> Bastian Blank writes ("Re: tag2upload (git-debpush) service
>> architecture - draft"): > T
Hello,
On Wed 31 Jul 2019 at 07:53AM +01, Rebecca N. Palmer wrote:
> (c-scriptedstatusquo) git debpush becomes an automated way to do what is
> currently recommended, i.e. it creates and pushes a signed git tag (to
> salsa and to dgit), creates tarballs, creates and signs .dsc+.changes,
> dputs
Hi Ian
On Wed, Jul 31, 2019 at 05:08:51PM +0100, Ian Jackson wrote:
> Bastian Blank writes ("Re: tag2upload (git-debpush) service architecture -
> draft"):
> > The hypothetical tool creates a complete .dsc file with the names and
> > checksums of the uncompressed
Ansgar writes ("Re: tag2upload (git-debpush) service architecture - draft"):
> There are also other issues, for example:
>
> - Such a service would bypass various sanity checks on the archive
>side, including various permission checks.
What permission checks are b
Bastian Blank writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> The hypothetical tool creates a complete .dsc file with the names and
> checksums of the uncompressed files. The user signed .dsc is put into
> the tag.
This tool is almost exactly "dgi
Bastian Blank writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> We discussed a bit within the ftp team and several points came up. The
> following describes my interpretation of it:
>
> The archive will need to do the final validation to check if a
On Mon, Jul 29, 2019 at 09:46:51 +0200, Ansgar wrote:
> There are also other issues, for example:
>
> - Such a service would bypass various sanity checks on the archive
>side, including various permission checks.
tag2upload checks the Debian Keyring and the DM ACL (from dak)/DM
keyring. What
There are at least 2 questions being debated here, and at least 5
proposed solutions, and they are frequently being confused.
The questions:
(1-trust) Is it acceptable in principle for the archive to trust a
tag2upload service? (i.e. have tag2upload rather than dak be
responsible for
On Sun, Jul 28, 2019 at 07:05:49PM +0100, Rebecca N. Palmer wrote:
> That suggests that working towards requiring the SHA-256 mode of git (which
> at least sort of exists since 2.21 [2], but I don't know if it's usable yet)
> might be a better use of effort.
Please keep in mind that the archive
Hello,
On Sun 28 Jul 2019 at 09:55PM +01, Rebecca N. Palmer wrote:
> On 28/07/2019 20:01, Sean Whitton wrote:
>> When I read your first e-mail what I thought you had in mind was just
>> this -- having git-debpush compute a stronger hash of the tree object
>> and add that to the tag metadata,
Bernd Zeimetz writes:
> On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:> As a way to avoid relying
> on SHA-1, would it work to have git-debpush
>> include a longer hash in the tag message, and tag2upload also verify
>> that hash?
>>
> The other idea would be to convince git upstream to use something
On Jul 28, Bernd Zeimetz wrote:
> So I think the best thing to do is to get sha256 working in git and
> force the usage of sha256 if you want to sign a tag for upload.
This cannot be a goal for this project since git upstream will need
apparently a few more years for the transition to sha-256
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:> As a way to avoid relying
on SHA-1, would it work to have git-debpush
> include a longer hash in the tag message, and tag2upload also verify
> that hash?
>
The other idea would be to convince git upstream to use something
better than sha1 - and
On 28/07/2019 20:01, Sean Whitton wrote:
When I read your first e-mail what I thought you had in mind was just
this -- having git-debpush compute a stronger hash of the tree object
and add that to the tag metadata, ignoring commit objects.
Of the files in the signer's repository, not of an
Hello,
On Sun 28 Jul 2019 at 07:05pm +01, Rebecca N. Palmer wrote:
> On 28/07/2019 16:18, Ian Jackson wrote:
>> What it amounts to is a parallel Merkle tree to the
>> git one, just with a different data format and a better hash.
>
> Not really: it wouldn't need the history tree structure (in Git
On 28/07/2019 16:18, Ian Jackson wrote:
What it amounts to is a parallel Merkle tree to the
git one, just with a different data format and a better hash.
Not really: it wouldn't need the history tree structure (in Git terms
[0], it would be a tree object not a commit object), and if we use
On 28/07/2019 10:58, Bernd Zeimetz wrote:
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:
As a way to avoid relying on SHA-1, would it work to have git-debpush
include a longer hash in the tag message, and tag2upload also verify
that hash?
what exactly would you create that long hash of?
The
Rebecca N. Palmer writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> The signer's local files when they run git-debpush. (To be decided: how
> to define the hash of a directory tree (as opposed to a single file),
> i.e. "tar | sha256 like a
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:
> As a way to avoid relying on SHA-1, would it work to have git-debpush
> include a longer hash in the tag message, and tag2upload also verify
> that hash?
what exactly would you create that long hash of?
If we don't trust sha-1, then we might also
As a way to avoid relying on SHA-1, would it work to have git-debpush
include a longer hash in the tag message, and tag2upload also verify
that hash?
Jonathan McDowell writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> For the record I am in favour of this as a service. I'm not a dgit user,
> but I am a salsa user who pushes release tags there and then uploads to
> the archive. Reducing this to a single
Hi Ian
On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote:
> We've had a number of peripheral conversations, and informal
> internal reviews, but I think it's the stage now to have a public
> design review etc. I'm CCing this to -devel because I just did a
> lightning talk demo of the
Hello,
On Fri 26 Jul 2019 at 08:50PM +01, Jonathan McDowell wrote:
> I've clarified with Ian that despite Sean's blog talking about the
> debian-keyring package the dgit infrastructure correctly uses the
> keyring in /srv/keyring.debian.org/ as deployed by DSA on the Debian
> infrastructure.
On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote:
> I wrote this draft design doc / deployment plan for the tag-to-upload
> service, perhaps best summarised by Sean like this:
>
> We designed and implemented a system to make it possible for DDs to
> upload new versions of packages
Hi all.
I wrote this draft design doc / deployment plan for the tag-to-upload
service, perhaps best summarised by Sean like this:
We designed and implemented a system to make it possible for DDs to
upload new versions of packages by simply pushing a specially
formatted git tag to salsa.
44 matches
Mail list logo
