Holger Levsen writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> > In my proposal the source package is reproducible (in the
> > "reproducible builds" sense)
On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> In my proposal the source package is reproducible (in the
> "reproducible builds" sense) from the uploader's signed git tag.
i'm confused. 'reproducible builds' is about creating bit by bit
identical binaries from a given source.
Joerg Jaspert writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> First off: I, for personal reasons, am a bit detached right now with
> anything Debian (though that should change soon). For that reason, I
> haven't read most of the mail threads, th
Hi,
I reviewed the whole thread and the point of friction is the requirement
to sign the .dsc file to make sure that the source package matches what
the maintainer intended to upload. Ian doesn't want the maintainer to have
to deal with the .dsc and the ftpmasters wants to have a signature within
On 15508 March 1977, Sam Hartman wrote:
First off: I, for personal reasons, am a bit detached right now with
anything Debian (though that should change soon). For that reason, I
haven't read most of the mail threads, though i skimmed over this one a
bit.
Scott> Your proposal completely
Bastian Blank writes:
> On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
>> I think this requirement is a bit incomplete, in that I don't
>> understand the use case that would lead you to want to do this. It's
>> more of a description of an implementation strategy than a use case,
Russ Allbery writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> For who-uploads, I think you just need a trusted metadata store somewhere,
> and recovering this from the PGP signatures on *.dsc files is not a great
> trusted metadata store (among
Tobias Frost writes:
> Not sure if I understood this correctly, but the MIA team (via echolon?)
> uses the information to tell us if there is an upload from a prossible
> MIA person. (IOW the person is still active.)
> I also use who-uploads occasionally to see if a sponsor knows about
>
PS: Please stop sending my copies of e-mails, I explicitely ask not to
by specifying Mail-Followup-To.
Hi Ian
On Wed, Aug 28, 2019 at 12:10:44PM +0100, Ian Jackson wrote:
> Tracing the archive contents back to uploader signatures is already
> complicated because of the difficulty of
Hi Sam
On Wed, Aug 28, 2019 at 09:42:56AM -0400, Sam Hartman wrote:
> During the DPL campaign, a number of people, including Joerg, made
> statements that I interpreted as explicitly wanting to make this change.
> That is, they wanted to move our authoritative source format to Git,
> possibly
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> I'm sure that Ian and Sean had been thinking about this before the
> DPL campaign. But I think in a very real sense, they took that
> discussion and tried to show us what
On August 28, 2019 1:42:56 PM UTC, Sam Hartman wrote:
>> "Scott" == Scott Kitterman writes:
>
>Scott> Today the authoritative repository for what's in Debian is
>Scott> the package archive. My read is you want to change it so
>Scott> that the package archive is an
Scott Kitterman writes ("Re: tag2upload service architecture and risk
assessment - draft v2"):
> This is an example of where I struggle with 'assume good faith'.
I'm sorry. I really am trying.
Although I have found it difficult at times, I think our conversation
here is valuab
> "Scott" == Scott Kitterman writes:
Scott> Today the authoritative repository for what's in Debian is
Scott> the package archive. My read is you want to change it so
Scott> that the package archive is an implementation detail hanging
Scott> off of a set of git repositories
Scott Kitterman writes:
> Several time people have said they feel it's important to be able to verify
> from contents of the archive.
Hi all,
Please forgive my ignorance if this is stupid, or if it's already been
discussed and I overlooked it. I'm not posing this as a suggestion, but
rather
On Wednesday, August 28, 2019 7:10:44 AM EDT Ian Jackson wrote:
> Bastian Blank writes ("Re: tag2upload service architecture and risk
assessment - draft v2"):
> > We don't want to be forced to trust ftp-master. We have reproducible
> > builds to verify the content of
Bastian Blank writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> We don't want to be forced to trust ftp-master. We have reproducible
> builds to verify the content of binary packages. We have the user
> signatures to verify source packag
On Wed, Aug 28, 2019 at 04:02:32PM +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 28, 2019 at 12:09:41AM -0400, Scott Kitterman wrote:
> > I also check that the signature validates when I download a package from
> > the
> > archive. I like the fact that this signature connects to a developer
On Wed, Aug 28, 2019 at 12:09:41AM -0400, Scott Kitterman wrote:
> I also check that the signature validates when I download a package from the
> archive. I like the fact that this signature connects to a developer key in
> the keyring.
I think this doesn't work for e.g. old packages whose last
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> Ian Jackson writes:
> > The mapping from git tag to .dsc is nontrivial. git tag to
> > .dsc construction (or verification) is complex and offers a
> > large attack surf
Scott Kitterman writes ("Re: tag2upload service architecture and risk
assessment - draft v2"):
> I sometimes use who-uploads from devscripts when I want to find out who
> actually did an upload. In theory, it could be re-written to support
> whatever.
As I mention in my
Scott Kitterman writes ("Re: tag2upload service architecture and risk
assessment - draft v2"):
> I haven't gone back and re-read the previous thread, but I did look at the
> risk assessment and I don't find it a serious response to concerns people
> raised.
I'm
On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
> Scott Kitterman writes:
> > As an example, I recall concerns about there not being an uploader
> > signature on the source anymore, so we would lose the ability to verify
> > from the archive who was responsible for the upload.
>
On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
> Scott Kitterman writes:
>
> > As an example, I recall concerns about there not being an uploader
> > signature on the source anymore, so we would lose the ability to verify
> > from the archive who was responsible for the upload.
>
On Tuesday, August 27, 2019 8:04:06 PM EDT Russ Allbery wrote:
> Scott Kitterman writes:
> > As an example, I recall concerns about there not being an uploader
> > signature on the source anymore, so we would lose the ability to verify
> > from the archive who was responsible for the upload.
>
>
Scott Kitterman writes:
> As an example, I recall concerns about there not being an uploader
> signature on the source anymore, so we would lose the ability to verify
> from the archive who was responsible for the upload.
Does anyone do this? Does it work today?
I'm dubious that you would be
On Tuesday, August 27, 2019 1:19:14 PM EDT Ian Jackson wrote:
> Ian Jackson writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> > [stuff]
>
> Argh. A bunch of people helped me refine this but I sent an early
> draft by mistake. I guess
> "Ian" == Ian Jackson writes:
Ian> From my reading of the thread, it seems that there are two
Ian> disputed design demands, which are related.
Ian> The most basic demand is that the archive should be able to
Ian> verify the whole contents of the .dsc, given data signed by
Ian Jackson writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> [stuff]
Argh. A bunch of people helped me refine this but I sent an early
draft by mistake. I guess it's too late to hope people will read only
the better version, but here it is an
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment -
draft v2"):
> I do think it would be valuable to confirm whether we're at an impasse.
> It sounds like Ian may think that resolving your concerns would be a
> no-go
I'm definitely trying to
Dear Bastian,
On Tue, Aug 27, 2019 at 02:41:28PM +0200, Bastian Blank wrote:
> No, you just did a medium break. Mail is not web, don't do that. You
> need to at least list the differences.
[...]
> Sorry, but I don't see how we can go forward, while you seem to be
> either unable to understand
> "Bastian" == Bastian Blank writes:
Bastian> Please describe the design changes you added to address our
Bastian> concerns. The risk assessment still lists things we
Bastian> described as no-go.
Bastian> Sorry, but I don't see how we can go forward, while you
Bastian>
On Tue, Aug 20, 2019 at 06:32:30PM +0100, Ian Jackson wrote:
> Thanks for all the comments on the draft service architecture I posted
> in late July. [1] I have made a v2, incorporating the various helpful
> suggestions, and the information from the thread.
No, you just did a medium break. Mail
Ian Jackson writes ("tag2upload service architecture and risk assessment -
draft v2"):
> Thanks for all the comments on the draft service architecture I posted
> in late July. [1] I have made a v2, incorporating the various helpful
> suggestions, and the information from the thread.
It has been
34 matches
Mail list logo
