From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Kliakhandler Subject: Re: Why no secure code retrieval Date: Sun, 3 Jul 2016 21:18:28 +0300 Message-ID: References: <87mvm4sewl.fsf@systemreboot.net> <87y45m28vp.fsf@saiph.selenimh> <87lh1k5dj1.fsf@free.fr> <20160702165130.GA1401@scamper2.bantercat.co.uk> <87eg7bnqob.fsf@free.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c05e6ec12dadd0536bf3f39 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJlyT-0002md-Hu for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 14:18:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJlyQ-0003iQ-Er for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 14:18:32 -0400 Received: from mail-it0-x234.google.com ([2607:f8b0:4001:c0b::234]:38707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJlyQ-0003gj-7T for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 14:18:30 -0400 Received: by mail-it0-x234.google.com with SMTP id h190so50780453ith.1 for ; Sun, 03 Jul 2016 11:18:29 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Robert Horn Cc: Bastien , emacs-orgmode@gnu.org, Arun Isaac , Ian Barton , Nicolas Goaziou --94eb2c05e6ec12dadd0536bf3f39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Robert, I am the OP. For what it is worth, the current discussion is actually precisely what I was aiming at. I agree with your analysis of my Intended goals but completely disagree that SHA1 alone is any sort of guarantee.. To be precise, I don't just think that it doesn't provide much, but rather that alone it provides none at all. This is because I have no idea who produced a given SHA1 - whether it was Bastien, or a MITM attacker, or just someone who compromised the server. Of course I don't care much about whether the code would be available via gitolite or gogs, or at least much less than that something would be available. Together with signing of releases tags it would be magnificent and actually *would* provide a significant level of guarantee (at least for me). Finally, I'd like to add that if the decision regarding the git hosting service comes down to such consideration, that gogs seems much more polished from a user perspective. Thanks, Kosta -- )=C2=B0))=C2=B0((=C2=B0( Konstantin Kliakhandler Sent on the go. I think that the original question was looking at a different problem, and discussion of hosted tooling may be a distraction. The issues that normally come up for cyber-security discussions of distribution need to be looked at. The following is a start at organizing those for org-mode. I think that the problem that started this discussion was a question about whether an org-mode user could verify the integrity and authenticity of an org-mode version distribution, or perhaps the integrity and authenticity of an installed version. It may be in the context of ELPA for that user. A full answer for all org-mode users would certainly include ELPA. I personally use a combination of "git clone" and "git checkout" to manage my org-mode versions. That provides adequate protection at the moment, but SHA1 is not sufficient in the long term. R Horn rjhorn@alum.mit.edu **** [2016-07-03 Sun 12:15] Org security ***** Org cyber-security ****** Process questions ******* How are security flaws discovered ******** Is there a known public reporting channel? ******** Are they privately and publicly tracked. For example, are CVE numbers obtained for public tracking, reporting, status, etc. ******** Are patches tracked relative to CVE numbers? ******** Are security-only patches and releases made? - For current development and release versions? - For widely deployed older versions? ******* Are security processes understood, maintained, staffed, performed? ****** Development process related questions I'll let these wait for now. ****** Release and Distribution process related questions ******* Org has multiple release and distribution chains. - The underlying git structure is used by developers and some of the end users - Direct git clone is used by some, and is one distribution chain - Git hosting is used by some. This is git plus extra hosting facilities - ELPA is used by some. - Tar-ball distribution is still used by some - Bundled distributions (Red Hat, Ubuntu, etc.) are used by some - Other distribution methods can be ignored for now (in my opinion) ******* How are releases identified? ******** GIT - GIT identifies changes and tagged releases by SHA1 hash. SHA1 hash remains excellent as integrity verification against accidental damage. SHA1 is end of life against intentional attack. It is expected to be vulnerable to well funded attackers by 2020. - see also below on verification and identification ******** GIT hosting depends on the host. ******** ELPA ELPA is seriously lacking, at least in terms of documentation. This is probably the source of the initial user question. ELPA can identify version strings. ******** Tar-ball Nothing appears to be set up for robust identification of tar balls for org-mode. ******** Bundled distributions Distributions have identification systems that do not always match the org-mode system. ******* How does distribution process protect integrity and authentication of a release? - Is there integrity check and authenticated verification from development release to end user installation? - Can an end user verify the integrity and authenticate the installed software? ******** GIT - GIT can provide PGP signing for tagged releases. Org does not currently use this feature. PGP signing is considered secure for integrity and authentication verification, provided the security processes are sufficient in the development release system. - GIT can provide PGP signing for individual updates. Org does not currently use this feature. PGP signing at the individual update level is often too burdensome for projects. Every committer must be familiar with PGP signing and properly protect their keys. There is a key management headache for project administration. ******** Git Hosting - Depends of the hosting. Hosted verification often changes the risks rather than eliminate them. If hosting facility protection is used instead of git PGP signing, the risk changes from PGP management flaws into host service user management flaws. Instead of PGP headaches there are the headaches from lost SSH keys and user spoofing. ******** ELPA - ELPA does not appear to have any verification or authentication capability ******** Tar-ball Nothing appears to be set up for verification or authentication of tar-balls for org-mode ******** Bundled distributions The bundled distributions use signed packages. Some distributions can verified installed packages, while others don't provide this feature. The distribution chain from "bundler" to end user install is well protected. Protection from org-mode developer to "bundler" is unknown. ******* Update process - When a new release is made, is integrity and authentication verified? to distributor? to end user? How difficult is this? - Is there a fast path for security patches? - Is there a special notification path to users for security patches? - Are security updates for older versions easily obtained and installed? --94eb2c05e6ec12dadd0536bf3f39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Robert,

I am the OP.

For what it is worth, the current discussion is actually pre= cisely what I was aiming at. I agree with your analysis of my Intended goal= s but completely disagree that SHA1 alone is any sort of guarantee.. To be = precise, I don't just think that it doesn't provide much, but rathe= r that alone it provides none at all. This is because I have no idea who pr= oduced a given SHA1 - whether it was Bastien, or a MITM attacker, or just s= omeone who compromised the server.

Of course I don't care much about whether the code would= be available via gitolite or gogs, or at least much less than that somethi= ng would be available. Together with signing of releases tags it would be m= agnificent and actually *would* provide a significant level of guarantee (a= t least for me).

Finally, I'd like to add that if the decision regarding = the git hosting service comes down to such consideration, that gogs seems m= uch more polished from a user perspective.

Thanks,
Kosta

--=C2=A0
)=C2=B0))=C2=B0((=C2=B0(=C2=A0
Konstantin Kliakhandler
Sent on the go.


I think that the original question was looking at a different problem,
and discussion of hosted tooling may be a distraction.=C2=A0 The issues tha= t
normally come up for cyber-security discussions of distribution need to
be looked at.=C2=A0 The following is a start at organizing those for
org-mode.

I think that the problem that started this discussion was a question
about whether an org-mode user could verify the integrity and
authenticity of an org-mode version distribution, or perhaps the
integrity and authenticity of an installed version.=C2=A0 It may be in the<= br> context of ELPA for that user.=C2=A0 A full answer for all org-mode users would certainly include ELPA.

I personally use a combination of "git clone" and "git check= out" to
manage my org-mode versions.=C2=A0 That provides adequate protection at the=
moment, but SHA1 is not sufficient in the long term.

R Horn
rjhorn@alum.mit.edu

**** [2016-07-03 Sun 12:15] Org security
***** Org cyber-security
****** Process questions
******* How are security flaws discovered
******** Is there a known public reporting channel?
******** Are they privately and publicly tracked.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, are CVE numbers obtained for= public tracking, reporting, status, etc.
******** Are patches tracked relative to CVE numbers?
******** Are security-only patches and releases made?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- For current development and release ver= sions?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- For widely deployed older versions?
******* Are security processes understood, maintained, staffed, performed?<= br> ****** Development process related questions
=C2=A0 =C2=A0 =C2=A0 =C2=A0I'll let these wait for now.
****** Release and Distribution process related questions
******* Org has multiple release and distribution chains.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - The underlying git structure is used by devel= opers and some of the end users
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Direct git clone is used by some, and is one = distribution chain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Git hosting is used by some.=C2=A0 This is gi= t plus extra hosting facilities
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - ELPA is used by some.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Tar-ball distribution is still used by some =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Bundled distributions (Red Hat, Ubuntu, etc.)= are used by some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Other distribution methods can be ignored for= now (in my opinion)
******* How are releases identified?
******** GIT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- GIT identifies changes and tagged relea= ses by SHA1 hash.=C2=A0 SHA1 hash remains excellent as integrity verificati= on against accidental damage.=C2=A0 SHA1 is end of life against intentional= attack.=C2=A0 It is expected to be vulnerable to well funded attackers by = 2020.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- see also below on verification and iden= tification
******** GIT hosting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0depends on the host.
******** ELPA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ELPA is seriously lacking, at least in te= rms of documentation.=C2=A0 This is probably the source of the initial user= question. ELPA can identify version strings.
******** Tar-ball
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nothing appears to be set up for robust i= dentification of tar balls for org-mode.
******** Bundled distributions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Distributions have identification systems= that do not always match the org-mode system.
******* How does distribution process protect integrity and authentication = of a release?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Is there integrity check and authenticated ve= rification from development release to end user installation?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Can an end user verify the integrity and auth= enticate the installed software?
******** GIT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- GIT can provide PGP signing for tagged = releases.=C2=A0 Org does not currently use this feature.=C2=A0 PGP signing = is considered secure for integrity and authentication verification, provide= d the security processes are sufficient in the development release system.<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- GIT can provide PGP signing for individ= ual updates.=C2=A0 Org does not currently use this feature.=C2=A0 PGP signi= ng at the individual update level is often too burdensome for projects.=C2= =A0 Every committer must be familiar with PGP signing and properly protect = their keys.=C2=A0 There is a key management headache for project administra= tion.
******** Git Hosting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Depends of the hosting.=C2=A0 Hosted ve= rification often changes the risks rather than eliminate them.=C2=A0 If hos= ting facility protection is used instead of git PGP signing, the risk chang= es from PGP management flaws into host service user management flaws.=C2=A0= Instead of PGP headaches there are the headaches from lost SSH keys and us= er spoofing.
******** ELPA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- ELPA does not appear to have any verifi= cation or authentication capability
******** Tar-ball
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nothing appears to be set up for verifica= tion or authentication of tar-balls for org-mode
******** Bundled distributions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The bundled distributions use signed pack= ages.=C2=A0 Some distributions can verified installed packages, while other= s don't provide this feature.=C2=A0 The distribution chain from "b= undler" to end user install is well protected.=C2=A0 Protection from o= rg-mode developer to "bundler" is unknown.
******* Update process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - When a new release is made, is integrity and = authentication verified? to distributor? to end user? How difficult is this= ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Is there a fast path for security patches? =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Is there a special notification path to users= for security patches?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Are security updates for older versions easil= y obtained and installed?

--94eb2c05e6ec12dadd0536bf3f39--