helpSavannah Administration - Support: sr #109093, Support and require cloning via...

 
 

sr #109093: Support and require cloning via https:// instead of git://, http://, svn://, or other insecure transport

Submitted by:  None
Submitted on:  Wed 13 Jul 2016 10:25:24 PM UTC
Votes:  50  
 
Category:  Source code repositories - anonymous access Priority:  5 - Normal
Severity:  6 - Security Status:  Done
Assigned to:  agn Originator Email:  -email is unavailable-
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Fri 17 Feb 2017 09:21:44 PM UTC, comment #7: 

Savannah now supports HTTPS access for source-code browsing and anonymous cloning.

closing this ticket.
 - assaf

Assaf Gordon <agn>
Site Administrator
Wed 08 Feb 2017 10:14:57 PM UTC, comment #6: 

I also think this has been completed.  At the least, I can now use https: to access the GNU make git repos, and I could not do that before.  My congrats to the Savannah admin team!

David A. Wheeler <dwheeler>
Wed 08 Feb 2017 01:31:18 PM UTC, comment #5: 

I believe this has been completed, thanks to the excellent (and tireless) work of Bob Proulx and others on the Savannah and FSF admin teams.  Please double-check and verify if this can be resolved.

Paul D. Smith <psmith>
Wed 19 Oct 2016 06:24:41 AM UTC, comment #4: 

I might want to add that this is also criteria C6 of the GNU ethical repository criteria.

https://www.gnu.org/software/repo-criteria.html

It appears that this issue was overlooked in the evaluation of Savannah (given an A grade)

https://www.gnu.org/software/repo-criteria-evaluation.html

To reiterate, while releases can generally be downloaded over HTTPS and verified by GNUGPG regardless, the same is not yet true for the developmental sources. As it stands right now, anyone who wants to download the developmental sources is vulnerable to spyware, backdoors, etc. being snuck in while it is in transit by anyone between the person's computer and the GNU servers (depending where one is in the world, that could go through the borders of several countries, most of which have governments who would not be above doing it, though probably only for targetted people).

Anonymous
Wed 03 Aug 2016 11:00:39 PM UTC, comment #3: 

This is something that would be very nice to see available...

Paul D. Smith <psmith>
Sat 30 Jul 2016 07:41:35 PM UTC, comment #2: 

I agree, supporting HTTPS on the repo is critically important.  This lack makes it easy for someone to launch a MITM attack on the code supported by Savannah.

Note that the Linux Foundation's "best practices" badge makes HTTPS a minimum requirement: <https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#sites_https>.

What's the blocker?  Is there anything that can be done to help?  Savannah already has the needed TLS certs, so I imagine that all that's needed is a minor configuration change.

David A. Wheeler <dwheeler>
Wed 13 Jul 2016 10:35:29 PM UTC, comment #1: 

(I am the "anonymous" who made the initial report.)

This really should be top priority.  Savannah **already** has the needed TLS certificates!  This is a security vulnerability that makes Savannah unusable to many (those who refuse to install software from insecure connections).

Demi Obenour <demimarie>
Wed 13 Jul 2016 10:25:24 PM UTC, original submission:  

Due to man-in-the-middle attacks, the only secure ways to clone a repository are HTTPS and SSH.  git://, http://, svn://, and others are all insecure.

However, Savannah recommends cloning via the insecure git:// protocol, and indeed it is not even possible to clone via the secure https:// protocol in many cases!  This is a security risk (remote execution of arbitrary code) for anyone who does an anonymous checkout of any project over an insecure means of transport.

Git (at least) provides a smart HTTP(S) server, which is much faster than the old "dumb HTTP" transport, and roughly as fast as SSH.  Performance of the git:// protocal is irrelevant as it is insecure.

The result for me is that I am not able to use the Git master of binutils-gdb to debug my Rust programs, among other problems.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by agn (Posted a comment)
  • -email is unavailable- added by psmith (Voted in favor of this item)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by dwheeler (Posted a comment)
  • -email is unavailable- added by dwheeler (Voted in favor of this item)
  • -email is unavailable- added by demimarie (Posted a comment)
  •  

    There are 50 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-02-17 agn StatusNone => Done
        Assigned toNone => agn
        Open/ClosedOpen => Closed
    2016-08-03 psmith Carbon-Copy- => Added psmith
    2016-07-30 dwheeler Carbon-Copy- => Added dwheeler

    Back to the top


    Powered by Savane 3.9