imported mails

1 files changed, 148 insertions, 0 deletions

diff --git a/tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom b/tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom
new file mode 100644
index 0000000..93932db
--- /dev/null
+++ b/tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom
@@ -0,0 +1,148 @@
+Return-Path: <ick-discuss-bounces@ick.liw.fi>
+X-Original-To: distix@pieni.net
+Delivered-To: distix@pieni.net
+Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221])

+	by pieni.net (Postfix) with ESMTPS id 6670942EEC

+	for <distix@pieni.net>; Sun,  1 Apr 2018 11:37:11 +0000 (UTC)
+Received: from platypus.pepperfish.net (unknown [10.112.101.20])

+	by yaffle.pepperfish.net (Postfix) with ESMTP id 0B725417C5

+	for <distix@pieni.net>; Sun,  1 Apr 2018 12:37:11 +0100 (BST)
+Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net)

+	by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian))

+	id 1f2bIM-0004FR-Vt; Sun, 01 Apr 2018 12:37:10 +0100
+Received: from [10.112.101.103] (helo=mx3.pepperfish.net)

+ by platypus.pepperfish.net with esmtps (Exim 4.80 #2 (Debian))

+ id 1f2bIL-0004FD-RI

+ for <ick-discuss@ick.liw.fi>; Sun, 01 Apr 2018 12:37:09 +0100
+Received: from mail.steve.org.uk ([176.9.183.102] helo=ssh.steve.org.uk)

+ by mx3.pepperfish.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)

+ (Exim 4.84_2) (envelope-from <steve@steve.org.uk>)

+ id 1f2bII-0004oH-Cm

+ for ick-discuss@ick.liw.fi; Sun, 01 Apr 2018 12:37:09 +0100
+DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;

+ d=steve.org.uk; s=20150726; h=References:In-Reply-To:Message-ID:Date:Subject:

+ From:Cc:To:Sender:Reply-To:MIME-Version:Content-Type:

+ Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:

+ Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:

+ List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;

+ bh=tai3oUY8wIGE9uoKrRpALz4Jsr7wkkb9GjT+IeETq9c=; b=R1hOKe5R5wlGuhh2dPlbbc9JF

+ YdutDBOrrXzIKPLxfxziEs+xlZJV2VC33e21PBJKntu9Xt9WcKbmWeZPpxZ1Phv2K0ja6YD8JGR/A

+ UOdy8IDgO+kR2JYHgPdmVmeOIIfS+TR34wkd67hOI/pPMNfVmRvdBt0w/33sB5tf8i5zM=;
+Received: from steve by ssh.steve.org.uk with local (Exim 4.89)

+ (envelope-from <steve@steve.org.uk>) id 1f2bI6-0002mi-FH

+ for ick-discuss@ick.liw.fi; Sun, 01 Apr 2018 11:36:54 +0000
+To: ick-discuss@ick.liw.fi
+Cc: 
+From: Steve Kemp <steve@steve.org.uk>
+Date: Sun, 01 Apr 2018 11:24:37 +0000
+Message-ID: <1522581877.10476.1@ssh.steve.org.uk>
+In-Reply-To: <1522571699.2971.5.camel@liw.fi>
+References: <1522571699.2971.5.camel@liw.fi>
+X-added-header: steve.org.uk
+X-Pepperfish-Transaction: a5f2-dac9-60da-1ebe
+X-Spam-Score: -1.9
+X-Spam-Score-int: -18
+X-Spam-Bar: -
+X-Scanned-By: pepperfish.net, Sun, 01 Apr 2018 12:37:09 +0100
+X-Spam-Report: Content analysis details: (-1.9 points)

+ pts rule name              description

+ ---- ---------------------- --------------------------------------------------

+ -0.0 T_RP_MATCHES_RCVD      Envelope sender domain matches handover relay

+ domain

+ -0.0 SPF_PASS               SPF: sender matches SPF record

+ -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%

+ [score: 0.0000]

+ 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
+X-ACL-Warn: message may be spam
+X-Scan-Signature: 3e0b2c8d84541a19cffce3c5c0904f3a
+Subject: Re: What's needed before ick is ready for others to use?
+X-BeenThere: ick-discuss@ick.liw.fi
+X-Mailman-Version: 2.1.5
+Precedence: list
+List-Id: discussions about the ick CI system <ick-discuss-ick.liw.fi>
+List-Unsubscribe: <https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi>,

+ <mailto:ick-discuss-request@ick.liw.fi?subject=unsubscribe>
+List-Archive: <http://listmaster.pepperfish.net/pipermail/ick-discuss-ick.liw.fi>
+List-Post: <mailto:ick-discuss@ick.liw.fi>
+List-Help: <mailto:ick-discuss-request@ick.liw.fi?subject=help>
+List-Subscribe: <https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi>,

+ <mailto:ick-discuss-request@ick.liw.fi?subject=subscribe>
+Sender: ick-discuss-bounces@ick.liw.fi
+Errors-To: ick-discuss-bounces@ick.liw.fi
+
+> This morning I've been pondering on the following question: should I

+> try to achieve "ready for others to use" as soon as possible, or

+> should I concentrate on making sure all existing functionality is of

+> high quality?

+

+  I think there are pros and cons to either approach, but one thing

+ that I'm struggling with myself is the documentation.

+

+  I would love to see an overview of all the moving parts:

+

+ * There is one ick-server / controller.

+  * This is what it needs

+  * This is how you configure it.

+

+ * There is one artifact server.

+  * This is what it needs.

+  * This is how you configure it.

+

+ * There are N-workers / worker-managers.

+  * This is what they need.

+  * This is how you configure them.

+

+  Right now I've spent more time than I'd enjoy getting the

+ package(s) installed - in the end I resorted to your debian repository

+ but even that wasn't sufficient.

+

+  Getting the artifact-server running, for example, required installation

+ of `python3-requests`.  There was also some confusion about

+`python-cliapp` being a dependency, but the code using `python3-cliapp`,

+ the latter of which couldn't be installed without forcing, as it

+ overwrote a file in the previous package.

+

+  The ansible role helps, but the random start-scripts in the top-level

+ are a distraction.

+

+> I am leaning towards the former. Perfectionism is good, but it makes

+> things take a really long time and if things take too long, I get de-

+> motivated. "Write shit, but fix it quickly."

+

+> What do you all think? Is there something you can think of that ick

+> must do before you'd be willing to give it a try?

+

+  I think your list is good, but I'd add documentation.  Right now

+ I suspect there is a security problem with the artifact server, but

+ despite reading the architecture guide I'm missing the ability to

+ confirm it.

+

+  I suspect these requests are both problems:

+

+     GET /blobs/../../../etc/passwd

+     PUT /blobs/../../../etc/owned

+

+  But the GET/PUT both require authentication that I don't know how

+ to handle.

+

+  Looking at `blob_store.py` we see the code mostly boils down to:

+

+    prefix + name

+

+  Where name is user-submitted.  But of course I might be missing

+ the obvious, maybe bottle is filtering ahead of this code.  If that

+ is the case then things are probably OK, but there is an obvious

+ design-decision: Should names be unique?  If two jobs both upload

+ an artifact called "latest-amd64.tar.gz" what happens?  Should

+ uploads be namedspaced on job?  Or should the second artifact upload

+ fail?

+

+

+Steve

+-- 

+https://www.steve.org.uk/

+

+_______________________________________________

+ick-discuss mailing list

+ick-discuss@ick.liw.fi

+https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi