* Why no secure code retrieval @ 2016-06-28 12:10 Konstantin Kliakhandler 2016-06-29 6:11 ` Arun Isaac 0 siblings, 1 reply; 15+ messages in thread From: Konstantin Kliakhandler @ 2016-06-28 12:10 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 779 bytes --] Hello everyone, I have continually been perplexed by the (apparent) lack of ways to retrieve the code for org-mode in a secure fashion, but always thought that I just haven't tried hard enough. Today it dawned on me that there probably simply is no such way. I know that https can be a bit tedious to setup so I am not asking for it (though I do think it would be great if it was enabled on the site in some fashion). However, gpg signing release tag commits is dead simple and would take a total of maybe 10 minutes of work over the lifetime of the project (please correct me if I'm wrong). Given this, is there a reason this is not being done? And if there is no reason, would it be possible to begin doing it, going forward? Thanks in advance for the consideration, Kosta [-- Attachment #2: Type: text/html, Size: 1022 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-06-28 12:10 Why no secure code retrieval Konstantin Kliakhandler @ 2016-06-29 6:11 ` Arun Isaac 2016-06-30 11:50 ` Nicolas Goaziou 0 siblings, 1 reply; 15+ messages in thread From: Arun Isaac @ 2016-06-29 6:11 UTC (permalink / raw) To: Konstantin Kliakhandler; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 538 bytes --] > However, gpg signing release tag commits is dead simple and would > take a total of maybe 10 minutes of work over the lifetime of the project > (please correct me if I'm wrong). I second this statement. GPG signing sounds good to me. We should do this. > I know that https can be a bit tedious to setup so I am not asking for it > (though I do think it would be great if it was enabled on the site in some > fashion). HTTPS is not so tedious these days with Let's Encrypt. https://letsencrypt.org/ We should set up HTTPS as well. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 472 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-06-29 6:11 ` Arun Isaac @ 2016-06-30 11:50 ` Nicolas Goaziou 2016-07-02 14:18 ` Bastien Guerry 0 siblings, 1 reply; 15+ messages in thread From: Nicolas Goaziou @ 2016-06-30 11:50 UTC (permalink / raw) To: Arun Isaac; +Cc: Bastien Guerry, emacs-orgmode, Konstantin Kliakhandler Hello, Arun Isaac <arunisaac@systemreboot.net> writes: >> However, gpg signing release tag commits is dead simple and would >> take a total of maybe 10 minutes of work over the lifetime of the project >> (please correct me if I'm wrong). > > I second this statement. GPG signing sounds good to me. We should do > this. GPG signing tags is OK, but I wouldn't like to request every commit to be signed. >> I know that https can be a bit tedious to setup so I am not asking for it >> (though I do think it would be great if it was enabled on the site in some >> fashion). > > HTTPS is not so tedious these days with Let's Encrypt. > > https://letsencrypt.org/ > > We should set up HTTPS as well. It would be nice, indeed. I'm Cc'ing Bastien for his opinion on the matter, and a possible step forward. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-06-30 11:50 ` Nicolas Goaziou @ 2016-07-02 14:18 ` Bastien Guerry 2016-07-02 16:51 ` Ian Barton 0 siblings, 1 reply; 15+ messages in thread From: Bastien Guerry @ 2016-07-02 14:18 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Arun Isaac, emacs-orgmode, Konstantin Kliakhandler Hi Nicolas, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > GPG signing tags is OK, but I wouldn't like to request every commit to > be signed. Agreed. >>> I know that https can be a bit tedious to setup so I am not asking for it >>> (though I do think it would be great if it was enabled on the site in some >>> fashion). >> >> HTTPS is not so tedious these days with Let's Encrypt. >> >> https://letsencrypt.org/ >> >> We should set up HTTPS as well. > > It would be nice, indeed. I'm Cc'ing Bastien for his opinion on the > matter, and a possible step forward. I discussed possible server enhancements with Robert Klein a few months ago. I'm considering paying for a digitalocean instance, with https via letsencrypt for both the website and git. I'm also considering switching from our current git setup to using Gogs (https://gogs.io): this would ease the process of adding new contributors, welcoming more org repositories, etc. The other solution would simply to use https://savannah.gnu.org. One remaining problem for both gogs and savannah is to ensure web references to commits are correctly redirected, which I think is one line of nginx configuration. I'm curious to know what people think about the switch to something like gogs*. Thanks, * gitlab seems too heavy, and I'm more experienced in maintaining gogs instances than gitlab instances. -- Bastien ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-02 14:18 ` Bastien Guerry @ 2016-07-02 16:51 ` Ian Barton 2016-07-03 7:09 ` Bastien Guerry 0 siblings, 1 reply; 15+ messages in thread From: Ian Barton @ 2016-07-02 16:51 UTC (permalink / raw) To: Bastien Guerry Cc: Arun Isaac, emacs-orgmode, Konstantin Kliakhandler, Nicolas Goaziou On Sat, Jul 02, 2016 at 04:18:42PM +0200, Bastien Guerry wrote: > Hi Nicolas, > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > > > GPG signing tags is OK, but I wouldn't like to request every commit to > > be signed. > > Agreed. > > >>> I know that https can be a bit tedious to setup so I am not asking for it > >>> (though I do think it would be great if it was enabled on the site in some > >>> fashion). > >> > >> HTTPS is not so tedious these days with Let's Encrypt. > >> > >> https://letsencrypt.org/ > >> > >> We should set up HTTPS as well. > > > I'm considering paying for a digitalocean instance, with https via > letsencrypt for both the website and git. > > I'm also considering switching from our current git setup to using > Gogs (https://gogs.io): this would ease the process of adding new > contributors, welcoming more org repositories, etc. > > The other solution would simply to use https://savannah.gnu.org. > > One remaining problem for both gogs and savannah is to ensure web > references to commits are correctly redirected, which I think is > one line of nginx configuration. > > I'm curious to know what people think about the switch to something > like gogs*. > > Thanks, > > * gitlab seems too heavy, and I'm more experienced in maintaining > gogs instances than gitlab instances. > > -- > Bastien > Not heard of Gogs before, although it looks nice. Another possiblity would be gitolite with cgit. Gitolite is very flexible and as a consequence can be hard to set up initially. The documentation is very comprehensive. It supports mirroring of repos. -- Best wishes, Ian. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-02 16:51 ` Ian Barton @ 2016-07-03 7:09 ` Bastien Guerry 2016-07-03 15:11 ` Robert Klein ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Bastien Guerry @ 2016-07-03 7:09 UTC (permalink / raw) To: Ian Barton Cc: Arun Isaac, emacs-orgmode, Konstantin Kliakhandler, Nicolas Goaziou Hi Ian, Ian Barton <lists@wilkesley.net> writes: > Not heard of Gogs before, although it looks nice. Another possiblity > would be gitolite with cgit. Gitolite is very flexible and as a > consequence can be hard to set up initially. The documentation is very > comprehensive. It supports mirroring of repos. I have no experience with gitolite. I encourage you to try gogs, it is very easy to install and maintain, and its interface is very engaging. The more gogs users and potential admins out there, the more comfortable I'll feel making the switch. -- Bastien ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 7:09 ` Bastien Guerry @ 2016-07-03 15:11 ` Robert Klein 2016-07-03 15:20 ` Achim Gratz 2016-07-03 16:57 ` Robert Horn 2 siblings, 0 replies; 15+ messages in thread From: Robert Klein @ 2016-07-03 15:11 UTC (permalink / raw) To: Bastien Guerry Cc: emacs-orgmode, Arun Isaac, Ian Barton, Nicolas Goaziou, Konstantin Kliakhandler Hi, I haven't been as active as I'd have liked in this matter... Bastien Guerry <bzg@gnu.org> wrote: > Hi Ian, > > Ian Barton <lists@wilkesley.net> writes: > > > Not heard of Gogs before, although it looks nice. Another possiblity > > would be gitolite with cgit. Gitolite is very flexible and as a > > consequence can be hard to set up initially. The documentation is > > very comprehensive. It supports mirroring of repos. > > I have no experience with gitolite. gitolite is easy. Configuration is one directory with a configuration file, one directory with ssh keys; Configuration looks like this: #+begin_src conf repo orgmode RW+ = kleinrob R = @all config gitweb.url = git@example.org:orgmode config gitweb.description = "orgmode test" config receive.denyNonFastforwards = true config receive.denyDeletes = true repo testing RW+ = @all R = daemon config gitweb.url = git@example.org:testing config receive.denyNonFastforwards = true config receive.denyDeletes = true #+end_src I have ~35 lines of script, another 35 lines of instructions plus the apache configuration to get gitolite running on a SLES server. Doesn't need cgit. > > I encourage you to try gogs, it is very easy to install and maintain, > and its interface is very engaging. The more gogs users and potential > admins out there, the more comfortable I'll feel making the switch. For Gogs installation on Debian Jessie I have a ~20 line script (plus ~10 lines for postgresql; some more for MySQL). I'm using only the gogs web server (no apache and/or nginx front-end). Have to be careful copy- and pasting the script though, as I have to enter passwords. Current git versions now also supports http-urls, so this shouldn'nt be an issue for both gits vs gitolite. Gogs requires users to be created for current contributors... No preference from my side, though I have some emotional distance to gogs... Best Robert ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 7:09 ` Bastien Guerry 2016-07-03 15:11 ` Robert Klein @ 2016-07-03 15:20 ` Achim Gratz 2016-07-03 16:57 ` Robert Horn 2 siblings, 0 replies; 15+ messages in thread From: Achim Gratz @ 2016-07-03 15:20 UTC (permalink / raw) To: emacs-orgmode Bastien Guerry writes: > I encourage you to try gogs, it is very easy to install and maintain, > and its interface is very engaging. The more gogs users and potential > admins out there, the more comfortable I'll feel making the switch. If it requires anything more than dropping in the public SSH keys for enabling contributors, then that's a no-go IMHO (and any other candidate that'd share this characteristic). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 7:09 ` Bastien Guerry 2016-07-03 15:11 ` Robert Klein 2016-07-03 15:20 ` Achim Gratz @ 2016-07-03 16:57 ` Robert Horn 2016-07-03 18:18 ` Konstantin Kliakhandler 2 siblings, 1 reply; 15+ messages in thread From: Robert Horn @ 2016-07-03 16:57 UTC (permalink / raw) To: Bastien Guerry Cc: emacs-orgmode, Arun Isaac, Ian Barton, Nicolas Goaziou, Konstantin Kliakhandler 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 16:57 ` Robert Horn @ 2016-07-03 18:18 ` Konstantin Kliakhandler 2016-07-03 18:25 ` Achim Gratz 2016-07-03 20:12 ` Robert Horn 0 siblings, 2 replies; 15+ messages in thread From: Konstantin Kliakhandler @ 2016-07-03 18:18 UTC (permalink / raw) To: Robert Horn Cc: Bastien, emacs-orgmode, Arun Isaac, Ian Barton, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 6363 bytes --] 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 -- )°))°((°( 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? [-- Attachment #2: Type: text/html, Size: 7137 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 18:18 ` Konstantin Kliakhandler @ 2016-07-03 18:25 ` Achim Gratz 2016-07-03 20:12 ` Robert Horn 1 sibling, 0 replies; 15+ messages in thread From: Achim Gratz @ 2016-07-03 18:25 UTC (permalink / raw) To: emacs-orgmode Konstantin Kliakhandler writes: > 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. Getting the same data via https doesn't give you that sort of guarantee either, it only ensures that the data cannot be read and altered in transport. If the server or repo gets compromised, then it is game over until someone notices that the server suddenly doesn't match up the local clone. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 18:18 ` Konstantin Kliakhandler 2016-07-03 18:25 ` Achim Gratz @ 2016-07-03 20:12 ` Robert Horn 2016-07-03 22:36 ` Konstantin Kliakhandler 1 sibling, 1 reply; 15+ messages in thread From: Robert Horn @ 2016-07-03 20:12 UTC (permalink / raw) To: Konstantin Kliakhandler Cc: Bastien, Ian Barton, Arun Isaac, emacs-orgmode, Nicolas Goaziou Konstantin Kliakhandler writes: > 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. The SHA1's are created by the git processes at the git server that you connect to. Or, in the case of a malicious source, by the malicious source appearing to be the git server. The SHA1's are reference elements used throughout git, and are primarily for integrity protection against accidents, not against attackers. Hence it's sufficient that they be maintained by the git processes. The plain vanilla git process does not include distribution of SHA1 values by an independent path, so it's not easy to verify against a trusted source for the correct values. As Achim Gratz says: >If the server or repo gets compromised, then it is game over >until someone notices that the server suddenly doesn't match up the >local clone. The most common and appropriate next step (assuming git is used for distribution) is to make use of PGP signing of tagged versions in git. This is a strong signature traceable to some release person or process. It provides strong verification and authentication for the contents of a specific tagged release. This protects against distribution server and repo compromises, but not against development process compromises. This would be a reasonable step for org-mode releases. The release process only involves a few people, and key management would not be too hard. It doesn't solve the problem for non-git distribution methods. My guess is that the ELPA users are the most exposed. Fixing that really belongs to ELPA, but if I were putting together the cyber security plan for org-mode I would call out this gap and make clear that it is a gap that can't be easily solved by org-mode. (Maybe tweaking someone more familier with ELPA to tell me how to solve it for ELPA.) Signed tags do not provide much extra protection for developers. The usual git process of using SSH keys to authenticate developers is much easier to manage than individually signed changes. It's vulnerable to all the usual attacks. Overall integrity depends upon the release testing and verification process. Signed commits can reduce these risks. Signed commits are a lot more work than the SSH key methods. I doubt that the committers have the appetite to deal with all the issues involved. R Horn ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 20:12 ` Robert Horn @ 2016-07-03 22:36 ` Konstantin Kliakhandler 2016-07-04 0:17 ` Robert Horn 0 siblings, 1 reply; 15+ messages in thread From: Konstantin Kliakhandler @ 2016-07-03 22:36 UTC (permalink / raw) To: Robert Horn Cc: Arun Isaac, Bastien, Stromeko, emacs-orgmode, Nicolas Goaziou, Ian Barton [-- Attachment #1: Type: text/plain, Size: 2993 bytes --] Hello, On 3 July 2016 at 23:12, Robert Horn <rjhorn@alum.mit.edu> wrote: > > The SHA1's are reference elements used throughout git, and are primarily > for integrity protection against accidents, not against attackers. Hence > it's sufficient that > they be maintained by the git processes. > Sufficient for what? I believe we were discussing security (that was my intention at least, and so did your previous email seem to indicate). And if this is the case, you have just contradicted yourself. I apologize for pointing it out so directly, and also if I misunderstood you. > The plain vanilla git process does not include distribution of SHA1 > values by an independent path, so it's not easy to verify against a > trusted source for the correct values. > Which trusted source? This is the whole point of said discussion. If I haven't a secure connection to the server and none of the commits are signed, what exactly are you proposing to compare to? My proposal was comparison to the gpg signatures in git itself, at least for tagged revisions. This would provide a canonical source to compare to, and can be done automatically by git itself (the comparison). I certainly can live off just tagged versions. Even when you want to fix a bug/add a feature, most likely you need to just work against files that haven't changed since last tag. With your permission I'll quote the entire message of Achim Gratz: > > Getting the same data via https doesn't give you that sort of guarantee > > either, it only ensures that the data cannot be read and altered in > > transport. If the server or repo gets compromised, then it is game over > > until someone notices that the server suddenly doesn't match up the > local clone. No, it does not give me a guarantee. But very few things do. Signatures come closer to that, although https://xkcd.com/538/ should convince you that it isn't a guarantee either. But who said that there will ever be a point when the server doesn't match the local clone? https://mikegerwitz.com/papers/git-horror-story But just because there are other ways to enter your house does not mean you should not put a lock on your front door. This would be a reasonable step for org-mode releases. The release > process only involves a few people, and key management would not be too > hard. It doesn't solve the problem for non-git distribution methods. > My guess is that the ELPA users are the most exposed. Fixing that > really belongs to ELPA, but if I were putting together the cyber > security plan for org-mode I would call out this gap and make clear that > it is a gap that can't be easily solved by org-mode. (Maybe tweaking > someone more familier with ELPA to tell me how to solve it for ELPA.) > I believe that these days elpa is accessed by default via https and that archives are signed, though please correct me here. Assuming it is the case, there isn't much one can do beyond the currently suggested steps, I think. Have a nice week, Kosta [-- Attachment #2: Type: text/html, Size: 4447 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-03 22:36 ` Konstantin Kliakhandler @ 2016-07-04 0:17 ` Robert Horn 2016-07-04 6:15 ` Konstantin Kliakhandler 0 siblings, 1 reply; 15+ messages in thread From: Robert Horn @ 2016-07-04 0:17 UTC (permalink / raw) To: Konstantin Kliakhandler Cc: Arun Isaac, Bastien, Stromeko, emacs-orgmode, Nicolas Goaziou, Ian Barton Konstantin Kliakhandler writes: > > Sufficient for what? I believe we were discussing security (that was my > intention at least, and so did your previous email seem to indicate). And > if this is the case, you have just contradicted yourself. I apologize for > pointing it out so directly, and also if I misunderstood you. Sufficient for current risk mitigation in my opinion. You disagree. We both agree that signed tags would be better. Choices are based on an evaluation of risks, threats, and mitigation costs. Emacs has had very few security vulnerabilities discovered. There are only 18 CVE since 2000. None of these allowed priviledge escalation, and the two most severe required local user assistance. So org-mode is not in a high risk location. That means that I look for very low cost steps, i.e., very simple easy changes. Signing tags falls into that category because it only affects a few people and is not particularly difficult to manage for very small groups. Another step that I would take is to establish and publish the planned security processes. These should be established and understood well before any event takes place. Taking adhoc reactive steps in an emergency often causes more problems. > I believe that these days elpa is accessed by default via https and that > archives are signed, though please correct me here. Assuming it is the > case, there isn't much one can do beyond the currently suggested steps, I > think. > I took a quick look inside package.el and it is still incomplete. It's also got a big todo list, so I expect this to change with subsequent releases. As of Emacs 24.3 ELPA did not have package signatures. Emacs 24.5 has package signatures, but no way for the user to verify that what is installed matches the signature. As of 24.5, the default behavior in package.el is: - package signatures are optional - package signatures are only checked to confirm that the tar file that is downloaded matches the signature. There is no tooling for subsequent verifications. - invalid signatures are ignored by default - missing signatures are ignored by default - package.el has dependencies on programs external to emacs. If these dependencies are not met, it reverts to default behavior. This is clearly better than 24.3. Again, in terms of risk/cost/mitigation evaluation I would have the tool that creates the ELPA package for org-mode also create a signature. It might do that already. Package.el does not indicate which packages are signed. I would let the folks taking care of ELPA deal with the rest in later releases. Use of https for most ELPA repositories does protect against in transit content corruption, but not necessarily much else. Looking at elpa.gnu.org I notice: - Their certificate expired today and has not been updated, oops - They use Let's Encrypt as signing authority. This means that the certificate verifies that whoever responds to the domain name http port controls the TLS certificate and web content. That's enough for many purposes, but it doesn't mean much in terms of server security. In transit MITM is a minor threat for software distribution. I've only detected MITM activity in public locations once in the real world. (I was thrilled. It's a really rare event.) It was in a very high threat location (Washington DC area, a public wifi). The big MITM threat is the dangers from malicious javascript insertion into unprotected browser activity. R Horn rjhorn@alum.mit.edu ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Why no secure code retrieval 2016-07-04 0:17 ` Robert Horn @ 2016-07-04 6:15 ` Konstantin Kliakhandler 0 siblings, 0 replies; 15+ messages in thread From: Konstantin Kliakhandler @ 2016-07-04 6:15 UTC (permalink / raw) To: Robert Horn Cc: Arun Isaac, Bastien, Stromeko, emacs-orgmode, Nicolas Goaziou, Ian Barton [-- Attachment #1: Type: text/plain, Size: 4098 bytes --] Thanks for the clarification and the detailed analysis. Sounds like you did you homework - I have a lot lo learn. Anyway, I would say that we agree on most points, and I'm more than content to leave it at that :-). Best Regards, Kosta -- )°))°((°( Konstantin Kliakhandler Sent on the go. On Jul 4, 2016 03:17, "Robert Horn" <rjhorn@alum.mit.edu> wrote: > > Konstantin Kliakhandler writes: > > > > > Sufficient for what? I believe we were discussing security (that was my > > intention at least, and so did your previous email seem to indicate). And > > if this is the case, you have just contradicted yourself. I apologize for > > pointing it out so directly, and also if I misunderstood you. > > Sufficient for current risk mitigation in my opinion. You disagree. > > We both agree that signed tags would be better. > > Choices are based on an evaluation of risks, threats, and mitigation > costs. Emacs has had very few security vulnerabilities > discovered. There are only 18 CVE since 2000. None of these allowed > priviledge escalation, and the two most severe required local user > assistance. So org-mode is not in a high risk location. > > That means that I look for very low cost steps, i.e., very simple easy > changes. Signing tags falls into that category because it only affects > a few people and is not particularly difficult to manage for very small > groups. > > Another step that I would take is to establish and publish the planned > security processes. These should be established and understood well > before any event takes place. Taking adhoc reactive steps in an > emergency often causes more problems. > > > I believe that these days elpa is accessed by default via https and that > > archives are signed, though please correct me here. Assuming it is the > > case, there isn't much one can do beyond the currently suggested steps, I > > think. > > > > I took a quick look inside package.el and it is still incomplete. It's > also got a big todo list, so I expect this to change with subsequent > releases. As of Emacs 24.3 ELPA did not have package signatures. Emacs > 24.5 has package signatures, but no way for the user to verify that what > is installed matches the signature. > > As of 24.5, the default behavior in package.el is: > - package signatures are optional > - package signatures are only checked to confirm that the tar file that > is downloaded matches the signature. There is no tooling for subsequent > verifications. > - invalid signatures are ignored by default > - missing signatures are ignored by default > - package.el has dependencies on programs external to emacs. If these > dependencies are not met, it reverts to default behavior. > > This is clearly better than 24.3. > > Again, in terms of risk/cost/mitigation evaluation I would have the tool > that creates the ELPA package for org-mode also create a signature. It > might do that already. Package.el does not indicate which packages are > signed. I would let the folks taking care of ELPA deal with the rest in > later releases. > > Use of https for most ELPA repositories does protect against in transit > content corruption, but not necessarily much else. Looking at > elpa.gnu.org I notice: > - Their certificate expired today and has not been updated, oops > - They use Let's Encrypt as signing authority. This means that the > certificate verifies that whoever responds to the domain name http port > controls the TLS certificate and web content. That's enough for > many purposes, but it doesn't mean much in terms of server security. > > In transit MITM is a minor threat for software distribution. I've only > detected MITM activity in public locations once in the real world. (I > was thrilled. It's a really rare event.) It was in a very high threat > location (Washington DC area, a public wifi). > > The big MITM threat is the dangers from malicious javascript insertion > into unprotected browser activity. > > R Horn > rjhorn@alum.mit.edu > [-- Attachment #2: Type: text/html, Size: 4763 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-07-04 6:16 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-28 12:10 Why no secure code retrieval Konstantin Kliakhandler 2016-06-29 6:11 ` Arun Isaac 2016-06-30 11:50 ` Nicolas Goaziou 2016-07-02 14:18 ` Bastien Guerry 2016-07-02 16:51 ` Ian Barton 2016-07-03 7:09 ` Bastien Guerry 2016-07-03 15:11 ` Robert Klein 2016-07-03 15:20 ` Achim Gratz 2016-07-03 16:57 ` Robert Horn 2016-07-03 18:18 ` Konstantin Kliakhandler 2016-07-03 18:25 ` Achim Gratz 2016-07-03 20:12 ` Robert Horn 2016-07-03 22:36 ` Konstantin Kliakhandler 2016-07-04 0:17 ` Robert Horn 2016-07-04 6:15 ` Konstantin Kliakhandler
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).