emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Why no secure code retrieval


From: Robert Horn
Subject: Re: [O] Why no secure code retrieval
Date: Sun, 03 Jul 2016 12:57:41 -0400
User-agent: mu4e 0.9.16; emacs 24.5.1

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
address@hidden

**** [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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]