Re: [Savannah-hackers-public] git over https

2017-02-07 Thread Leo Famulari
On Tue, Feb 07, 2017 at 03:18:32PM -0700, Bob Proulx wrote:
> Leo Famulari wrote:
> > I bet that most of them use the unauthenticated HTTP or Git protocols
> > and are vulnerable to man-in-the-middle attacks and eavesdropping.
> 
> Certainly it is vulnerable to easedropping.  And to some extent https
> metadata is also vulnerable too.  And since all of the hosted projects
> that might be downloaded is available to anyone I think that even with
> https it is possible for a well funded attacker with access to the
> metadata to know what someone has downloaded.  But with git using SHA1
> hashes for everything I think it would be quite the challenge to
> produce a viable modification attack.  (However I acknowledge that
> some of the proof of concept attacks for other attacks that I have
> looked at have quite surprised me by the cleverness used and that they
> did work.)

I don't think that the SHA1 hashes can protect somebody who is doing
`git clone` against MITM, because they would not already have a SHA1
graph that would become broken.

For `git fetch`, the attacker could add their changes after the most
recent commit.

> > I think this is a regression from the old Savannah server. The old
> > server appears to use the so-called "smart HTTP" Git protocol [0], which
> > provides informative output while it is working. On the other hand, the
> > "dumb HTTP" Git protocol [1] does not provide any output.
> 
> Drat!  This does appear to be a regression.
> 
> In your opinion is that enough of a regression to warrent reverting
> (once again) the git service back to the old server?  Of course that
> means another IP address change thrash for people who have ssh
> configured to watch such things.  And more delay in getting things
> moved.  Sigh.

I'm not sure, because I've never set up the "smart" protocol, and thus
have never been able to compare them from the same server. Perhaps one
of them is more efficient, but I don't know. The only difference I've
noticed as a user is the informative output. I think it's a major
improvement to offer HTTPS, so perhaps the "smart" protocol can be saved
for later.



Re: [Savannah-hackers-public] git over https

2017-02-07 Thread Leo Famulari
On Tue, Feb 07, 2017 at 02:29:36PM -0500, Paul Smith wrote:
> I'm not asking for _authenticated_ HTTPS support, just anonymous access
> over HTTPS.  More straightforwardly, I'm looking for HTTPS as an
> alternative to our current HTTP support, not an alternative to our
> current SSH support.

I'd like to clarify what I meant by "authenticated", just in case anyone
was confused. I'm only interested in using HTTPS to authenticate the
server to the client. It's possible to do it the other way around, but I
don't think it's necessary since anyone can use SSH.

So, I concur with Paul.



Re: [Savannah-hackers-public] git status update

2017-02-07 Thread Leo Famulari
On Tue, Feb 07, 2017 at 02:04:30PM -0700, Bob Proulx wrote:
> I switched git dns over to the new server (again) this morning.
> Trying not to thrash the IP address for git+ssh users too often.
> Everything git core command specific looks okay for my testing.

I pushed a commit to 
(208.118.235.201) and noticed this:

--
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 1.50 KiB | 0 bytes/s, done.
Total 5 (delta 3), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote:   File "hooks/post-receive", line 6, in 
remote: import git_multimail
remote: ImportError: No module named git_multimail
To ssh://git.sv.gnu.org/srv/git/guix.git
   4621acfd8..f0d0c5bb1  master -> master
--

The latest commits do seem to be missing from the guix-commits mailing
list archive:

https://lists.gnu.org/archive/html/guix-commits/2017-02/threads.html

I guess that it's having trouble with this thing:

https://github.com/git-multimail/git-multimail



[Savannah-hackers-public] Downstream questions about Savannah and HTTPS

2017-02-11 Thread Leo Famulari
GNU Guix is discussing the possibilities created by Savannah's offering
of Git-over-HTTPS:

http://lists.gnu.org/archive/html/guix-devel/2017-02/msg00386.html

If anyone from Savannah has anything to add to the discussion, feel free
to jump in :)



Re: [Savannah-hackers-public] Serving Git over HTTPS

2016-11-25 Thread Leo Famulari
On Wed, Nov 23, 2016 at 02:30:54AM -0700, Bob Proulx wrote:
> Leo Famulari wrote:
> > I wonder, is it technically feasible to serve
> > <http://git.savannah.gnu.org> over HTTPS?
> > 
> > That would give anonymous users privacy and some measure of authenticity
> > when fetching the source code of hosted projects.
> 
> This capability has been worked on by the Savannah Hackers team for
> some time.  It is almost ready.  It hasn't been possible on the
> existing system but will soon be possible as we migrate to an updated
> one.  Stay tuned for announcements on the main Savannah web page.

That's great news! I'm looking forward to it!



[Savannah-hackers-public] Serving Git over HTTPS

2016-11-13 Thread Leo Famulari
Greetings throughout the sunny Savannah!

I wonder, is it technically feasible to serve
 over HTTPS?

That would give anonymous users privacy and some measure of authenticity
when fetching the source code of hosted projects.


signature.asc
Description: PGP signature


[Savannah-hackers-public] "Stay in secure (https) mode after login"

2017-03-14 Thread Leo Famulari
The Savannah login page includes a checkbox that reads "Stay in secure
(https) mode after login".

Just to see what would happen, I logged in with this box unchecked. I
ended up at . I couldn't convince Savannah
and my browsers to log me in to .

So I'm wondering, what does that checkbox do? Is there still a
possibility that some communication will pass over unauthenticated
channels?

While logged in, I manually entered the HTTP URL and was still able to
access the administration interface for a group that I administer over
the unauthenticated connection.


signature.asc
Description: PGP signature


Re: [Savannah-hackers-public] "Stay in secure (https) mode after login"

2017-03-14 Thread Leo Famulari
On Tue, Mar 14, 2017 at 03:59:18PM -0400, Leo Famulari wrote:
> The Savannah login page includes a checkbox that reads "Stay in secure
> (https) mode after login".
> 
> Just to see what would happen, I logged in with this box unchecked. I
> ended up at <https://savannah.gnu.org/>. I couldn't convince Savannah
> and my browsers to log me in to <http://savannah.gnu.org/>.
> 
> So I'm wondering, what does that checkbox do? Is there still a
> possibility that some communication will pass over unauthenticated
> channels?
> 
> While logged in, I manually entered the HTTP URL and was still able to
> access the administration interface for a group that I administer over
> the unauthenticated connection.

I should have searched the archives before sending this message. The
subject has already been discussed:

http://lists.gnu.org/archive/html/savannah-hackers-public/2014-01/msg2.html

And more generally:

http://lists.gnu.org/archive/html/savannah-hackers-public/2016-10/msg2.html


signature.asc
Description: PGP signature


Re: [Savannah-hackers-public] "Stay in secure (https) mode after login"

2017-03-15 Thread Leo Famulari
On Wed, Mar 15, 2017 at 11:26:16AM -0400, Assaf Gordon wrote:
> There is an on-going discussion about forcing HTTPS everywhere on savannah.

I think that would be a good thing.

> Can you provide a specific example of a URL you can access in HTTP,
> and it allows you to make changes (I don't doubt it's possible, just need a 
> pointer
> to ease testing).

I'm not going to actually try adding or removing users from the group,
but I can load this page while logged in:

http://savannah.gnu.org/project/admin/useradmin.php?group=guix


signature.asc
Description: PGP signature


Re: [Savannah-hackers-public] vcs0 disk filling up, /var/cache/cgit again

2017-03-13 Thread Leo Famulari
On Mon, Mar 13, 2017 at 11:35:30AM -0600, Bob Proulx wrote:
> I am also seeing a lot of cgit snapshot activity.  Across all of the
> projects.  Here is one example.
> 
>   [13/Mar/2017:12:34:45 -0400] "GET /cgit/guix.git/snapshot/master.tar.gz 
> HTTP/1.1" 200 11642975 "-" "GNU Guile"

This is used in Guix as part of our update mechanism.

Specifically, the command `guix pull` [0] downloads that snapshot to
accomplish something that you can consider analogous to `apt-get update`
on dpkg / apt systems.

We plan for `guix pull` to evolve to use Git directly rather than
downloading a tarball, but we aren't there yet.

[0]
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pull.scm



[Savannah-hackers-public] Git CVE-2017-8386 (auth bypass via git-shell)

2017-06-07 Thread Leo Famulari
Dear Savannah,

CVE-2017-8386 [0] was recently fixed for Git. This bug allows remote users
to bypass authentication restrictions in git-shell and possibly have
other impacts.

This bug was fixed in upstream Git maintenance releases Git v2.4.12,
v2.5.6, v2.6.7, v2.7.5, v2.8.5, v2.9.4, v2.10.3, v2.11.2, and v2.12.3.
Apparently, 2.12.3 included some more unnamed security fixes:

http://marc.info/?l=linux-kernel=149437481723960=2

Does Savannah use git-shell? Has anybody looked into this yet?

[0]
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8386
Fix commit:
https://git.kernel.org/pub/scm/git/git.git/commit/?id=3ec804490a265f4c418a321428c12f3f18b7eff5


signature.asc
Description: PGP signature


Re: [Savannah-hackers-public] Git CVE-2017-8386 (auth bypass via git-shell)

2017-06-07 Thread Leo Famulari
On Wed, Jun 07, 2017 at 09:54:54PM +, Assaf Gordon wrote:
> Hello
> 
> On Wed, Jun 07, 2017 at 04:39:59PM -0400, Leo Famulari wrote:
> 
> > CVE-2017-8386 [0] was recently fixed for Git. This bug allows remote users
> > to bypass authentication restrictions in git-shell [...]
> > Does Savannah use git-shell? Has anybody looked into this yet?
> 
> Thank you for alerting us to this issue.
> 
> Savannah does use 'git-shell',
> but we're also using a standard GNU/Linux distribution,
> and the fixed version was already in place as part
> of the automatic daily security updates
> (verified manually by Bob Proulx, just now).

Awesome, thanks for double-checking.

> Please do continue to send us such alerts if they seem relevant -
> another look can never hurt.
> 
> If you (or others) discover a new vulnerability with savannah,
> we encourage everyone to report it to us private at:
>   savannah-hackers-private (at) gnu (dot) org .
> We will work with you quickly to resolve it,
> and then of course make it public.

Okay, I'll do that in the future.


signature.asc
Description: PGP signature


Re: [Savannah-hackers-public] VERY slow git response from Savannah

2018-02-21 Thread Leo Famulari
On Wed, Feb 21, 2018 at 12:45:24PM -0700, Bob Proulx wrote:
> arn...@skeeve.com wrote:
> > I would have thought most people would do 'git pull' instead of 'git clone'
> > and that pulling wouldn't be quite as intensive, but who knows...
> 
> I think that these days most people do not keep persistent state.  The
> cynic in me assumes they are working from their phone.  Instead they
> clone a new repository, do something, then toss it away.  Even for
> continuous integration systems many people do not use a local cache.
> I can't prove this but it is just my observation of the way people
> work around me in real life.  This makes large projects very I/O
> intensive when things happen.

As a relative young'un with a smartphone, I can say that doing
development on my phone sounds like a bad time! I typically keep full
clones around, even for one-off things. Source code is small and
gigabytes are cheap.

> I was actually using clone generically there.  But if people were
> pulling then I would have expected the processes to have finished
> quickly.  But we do periodically see large repositories getting cloned
> at the same time due to project announcements all run at the same time
> and take up time.  I don't know which projects were getting pulled or
> cloned since we do not log that information.  But previously Emacs has
> been the cause of it becaues the repos is large (and originally was
> larger) making cloning need a lot of bandwidth.  When Emacs announces
> a new release there is usually a spike.  So using it as an example
> without saying that was the project this time.

I imagine there are CI systems that do full clones and then check out
the commit they want. Of course this is a big waste of bandwidth, so in
Guix we are looking into the possibility of shallow cloning for related
use cases. This may be less efficient on the server; I guess it depends
on the server implementation. Still, we favor release tarballs because
they are small and the required software is much less complex.


signature.asc
Description: PGP signature


[Savannah-hackers-public] [task #15922] Savannah project memberlists do not load (HTTP 500)

2021-03-24 Thread Leo Famulari
URL:
  

 Summary: Savannah project memberlists do not load (HTTP 500)
 Project: Savannah Administration
Submitted by: lfam
Submitted on: Wed 24 Mar 2021 07:23:42 PM UTC
 Should Start On: Wed 24 Mar 2021 12:00:00 AM UTC
   Should be Finished on: Wed 24 Mar 2021 12:00:00 AM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

I noticed that the Guix project's Savannah "memberlist" is failing to load
with an HTTP 500 error.

https://savannah.gnu.org/project/memberlist.php?group=guix

This was working recently, I think within the last week.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/