X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by lists.alpinelinux.org (Postfix) with ESMTP id 3E1345C4E55 for ; Fri, 9 Feb 2018 11:39:10 +0000 (GMT) Received: by mail-wr0-f171.google.com with SMTP id 41so7901543wrc.9 for ; Fri, 09 Feb 2018 03:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=t22Wj5aXZlpAGTqZp6LbCmmgbOdv7YXMXks7v5eAtHM=; b=oCIs3mZsYIs36CVgTVn5wae55wCEOXjPfxdwzZO3cSqmKNLzHeziKH3ub8UFaJbvq6 No/7mxjz4ZHG3Y7TW17UHSgq4yR9VzMI1FjmAD4fI1VJoXS6w2pn2skb6nL1Nj0CaRr4 HyU6z66/Jhc7rc8mSv++ThcGEUHS4/mL15+sc1C6zi4pOpUuTFjBUhPvZU4t+0DXyyWl H9yq8BCfiCYKrNsP64ueFhxieYFB5WqKxSuHXxKM1gtUvgTCJkRRDpqxmxkkdfHAv8Kb xkHrSvMT2i6dRDYqR8ASeduLWKAICJOfnjV0TzdfhyUS4Lgyb2gptdlw07/OJYQYrO6w 2cTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=t22Wj5aXZlpAGTqZp6LbCmmgbOdv7YXMXks7v5eAtHM=; b=WFoj63iuToRPP7skznLgMFST5nM+lRDUESlNT43GnPvN+omVc50YAnngo3x0BjehoW 80jTD+G1MHqAYmFcwqatjO/h0ie/rd9c1LM55ckAKO8x4dYv5TVyN4MXTVMCICav8s1X 2qhzeNPqN7fO/IY9Z9aa9DMbuCkHSyTbBXh1tyCmF4XMoKGR3S2rS2o1PzBnoz84kBfz xgT+4rMF9Fhb+zWSrS5JGwFGctXAnFv6ueNxyWbNWNj2q6YCho+7vHYY28+Ov63mxOpT ikblbPAxTLUtj4yUWWsXL+c1KDaJTZTad+x0EaOCufc4lthqGfSsdxNQEoa0lRi39Bga 3vzg== X-Gm-Message-State: APf1xPBKqcHv4ahE/F/xBq7JL3GiP0CjYHqheVX83NE+pw0Il3l3w9Xc gNOaqU0uIkYIlc8I0DHkH72SJmM= X-Google-Smtp-Source: AH8x224bGc11sxVnzAmU5NHtPPSVArDPATudQFJMk/L5YgZA1p3nyw/HhMRITSLRXeLUwg9iS9yw3w== X-Received: by 10.223.146.66 with SMTP id 60mr2346485wrj.85.1518176349100; Fri, 09 Feb 2018 03:39:09 -0800 (PST) Received: from mechanicum.chadwicks.me.uk (mail.oesys.co. [82.71.11.172]) by smtp.gmail.com with ESMTPSA id c14sm3400246wmh.2.2018.02.09.03.39.08 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Feb 2018 03:39:08 -0800 (PST) Date: Fri, 9 Feb 2018 11:38:55 +0000 From: Kevin Chadwick To: alpine-dev Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl implementation Message-ID: <20180209113855.7e846ef4@mechanicum.chadwicks.me.uk> In-Reply-To: References: <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk> <20180208224032.3942ce38@mechanicum.chadwicks.me.uk> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 8 Feb 2018 17:43:31 -0600 > Hello, > > On Thu, Feb 8, 2018 at 4:40 PM, Kevin Chadwick > wrote: > >> > You clearly do not know about the extra protections and > >> > priviledge separation in LibreSSL!!! > >> > >> You must be talking about Pledge, which allows LibreSSL to declare > >> what system calls it will and will not be using. Of course, Pledge > >> is only available in OpenBSD. > > > > No, Pledge is not priviledge seperation or even close to it, though > > it does benefit from it! > > > > Buffer overflows are far less dangerous with priviledge separation > > deployed and no the way you compile Alpine will not accomplish > > anything like proper priviledge seperation. > > Alpine has been using privilege separation for years where possible > regardless of using LibreSSL or not. Privilege separation would not > have prevented Heartbleed, as the unprivileged process would still > require a copy of the X509 objects in order to perform cryptographic > operations. Cool, glad to hear it. My faith in Alpine is restored somewhat :) That depends on the design which is also why I said compilation wouldn't cut it. http://insanecoding.blogspot.co.uk/2014/05/protecting-private-keys.html https://marc.info/?l=openbsd-cvs&m=139879883203226&w=2 > > _______________________________________________________________________ > > > > As the OpenBSD 5.7 development effort comes to a close, so does the > > LibreSSL 2.1.x branch. The next release will begin the 2.2.x > > development branch. > > > > User-visible features: > > > > * Improvements to libtls: > > - a new API for loading CA chains directly from memory instead > > of a file, allowing verification with privilege separation in a > > chroot without direct access to CA certificate files. > > ________________________________________________________________________ > > This type of design is not provided by libtls itself, but libtls > provides the primitives for it. It is also possible to accomplish > this design through the OpenSSL 1.0.1g API using a series of > SSL_CTX_add0_chain_cert() calls (which is essentially what libtls does > internally), or just loading the certificate chain into X509 objects > prior to calling fork(2). And I am fairly sure the feature python wants is very simple and a lot easier than that and not difficult security wise (oring etc.). My question is, whether they have an agenda. Perhaps the build issues here are different and not fully understood by me though. I originally thought it was simply the following API call being desired and I am under the impression LibreSSL will cater for it and it wouldn't land in stable until 2019. https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PARAM_set1_host.html A much larger list has been shown with build issues that I cannot look into so... It was just the tone of the message that made me respond. Regards --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---