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

[Bob Proulx]

Leo Famulari wrote:
> 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

Thank you for that report.  This is the git-multimail hook.  There are
several different versions in use because different projects have
wanted different things.  This one wasn't installed on the new
system.  I installed it and I think it should be working now.

> To ssh://git.sv.gnu.org/srv/git/guix.git
>4621acfd8..f0d0c5bb1  master -> master

I will trigger the post-receive hook for this commit and use it to
verify that it is working.

> I guess that it's having trouble with this thing:
> 
> https://github.com/git-multimail/git-multimail

Yes.  That is what we are using.  Along with a half dozen other
versions and alternatives! :-)

Bob

Re: [Savannah-hackers-public] bzr post-commit email hook (was: gsrc-commit auto messages stopped working)

[carl hansen]

still still not working

On Tue, Jan 24, 2017 at 2:08 PM, carl hansen 
wrote:

> still not working
>
> On Sun, Jan 22, 2017 at 1:23 PM, Assaf Gordon 
> wrote:
>
>> Hello Carl,
>>
>> > On 01/20/2017 03:42 AM, carl hansen wrote:
>> >> When I commit to the bzr repository it used
>> >> to send a message automatically to "gsrc-com...@gnu.org". Since Jan
>> 5, that
>> >> has not happened. Probably an untied shoelace somewhere.
>>
>>
>> I've installed the missing bazaar plugin.
>> Please let us know if the commit emails are ok now.
>>
>> regards,
>>  - assaf
>>
>>
>>
>>
>> For savannah admins / future reference:
>>
>> Bazaar plugins guide:
>>  http://doc.bazaar.canonical.com/plugins/en/
>>
>>
>> Luckily the plugin was available as a package:
>>  http://packages.trisquel.info/belenos/bzr-email
>>
>>
>> Current bzr plugins on the new 'vcs0':
>> 
>> # bzr plugins
>> bash_completion 2.7.0dev1
>>   Generate a shell function for bash command line completion.
>> changelog_merge 2.7.0dev1
>>   Merge hook for GNU-format ChangeLog files
>> email
>>   Sending emails for commits and branch changes.
>> etckeeper
>>   Runs etckeeper pre-commit when necessary.
>> grep 2.7.0dev1
>>   Print lines matching PATTERN for specified files and revisions.
>> launchpad 2.7.0dev1
>>   Launchpad.net integration plugin for Bazaar.
>> loggerhead 1.18.1
>>   Loggerhead web viewer for Bazaar branches.
>> netrc_credential_store 2.7.0dev1
>>   Use ~/.netrc as a credential store for authentication.conf.
>> news_merge 2.7.0dev1
>>   Merge hook for bzr's NEWS file.
>> po_merge 2.7.0dev1
>>   Merge hook for ``.po`` files.
>> weave_fmt 2.7.0dev1
>>   Weave formats.
>> 
>>
>>
>

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

[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

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

[Bob Proulx]

Leo Famulari wrote:
> Bob Proulx wrote:
> > 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.

I guess we get to avoid that question.  I researched the task and have
been tinkering the configuration together today.  I will copy the
nginx configuration here in case other people need to do the same
thing.  This would work for most people.

This isn't the final configuration though since this uses the package
installed git, which should be fine but doesn't support shallow clones
with --depth 1 yet as of the OS Trisquel 7 release with git 1.9.1.
Therefore we are using git from a Debian Jessie Stable chroot with git
2.1.4.  The reason to use the chroot is to get a stable release with a
community supported security release stream.  Therefore I need to
point it to the custom version from the chroot.  Then everything
should be working.

Bob

location = /git { return 302 $request_uri/; }
location /git/ {
location ~ /git(/.*) {
gzip off;
include fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME 
/usr/lib/git-core/git-http-backend;
fastcgi_param PATH_INFO $1;
fastcgi_param GIT_HTTP_EXPORT_ALL true;
fastcgi_param GIT_PROJECT_ROOT /srv/git;
client_max_body_size 0;
}
}

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

[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

[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

[Bob Proulx]

Paul Smith wrote:
> 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 was able to use the new server without any issues.  I was also able
> to use HTTPS transport to clone anonymously... yay!

Yay! :-)

Thanks for the feedback.

Bob

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

[Bob Proulx]

Leo Famulari wrote:
> The advantage of HTTPS compared to SSH is that it can be used
> anonymously, without setting up a Savannah account. Currently, users who
> wish to fetch source code from Savannah using an authenticated protocol
> must create a Savannah account. This is inconvenient for casual users.

I am sympathetic.  And as you know we are heading toward https
everywhere that https can be used.  However you would not believe how
many things need significant effort in order to get there.  Because
over the decades the collection of services that is Savannah has
acquired quite a few features and warts.  Just git itself has moved
back and forth a half dozen times and been reverted due to showstopper
problems due to previously unknown conflicts.  It seemed a lot simpler
to me too before I became sucked into the machinery. :-)

> 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.)

> For this reason, I would not call HTTPS a fallback method, but
> rather in the same class as SSH.

I disagree.  I don't think https is in the same league here.  But that
doesn't mean I am trying to stop https.  Far from it.  I have put in a
lot of time trying to get everything moving forward.  It is available
now.

> >   git clone https://git0.savannah.gnu.org/git/emacs.git
> > Cloning into 'emacs'...
> > ... takes about twenty minutes with no output on my network ...
> 
> 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.

> It takes me ~40 seconds to clone the Guix Git repository from
> . To me, that's pretty fast
> for an 83 MB download. And it's the same speed as cloning over SSH from
> the old server.

Of course I chose Emacs because it has a large repository of about
275M and my network is probably slower. :-)

Bob

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

[Paul Smith]

On Tue, 2017-02-07 at 14:04 -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 was able to use the new server without any issues.  I was also able
to use HTTPS transport to clone anonymously... yay!

[Savannah-hackers-public] New kernels, fresh reboots all around

[Bob Proulx]

Just fyi...  New security kernels were released yesterday.  I
installed them.  Which means reboots all around.  I just now rebooted
all of the new VMs that received the new kernels.  All good!

Bob

[Savannah-hackers-public] git status update

[Bob Proulx]

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.
Specifically the shallow checkouts using --depth 1 that were the
previous problem are working now.

But the cgit web server was returning a proxy error.  In order to
avoid needing to debug that on the spot I proxied it over to the old
server temporarily.  That is running okay this way for the moment.
Can debug the local native server at our leisure.

Running through the tests pointed to robots.txt not working.  (Let me
praise having tests as being a really good thing.)  Debugging that
showed nginx config behavior I had not realized.  The "location /r"
section matches /robots.txt.  I used "location = /r" to create an
explicit redirect match for it that avoided substring matches.

Everything is functioning.  Need to figure out the native cgit
problem but no one else is seeing that.

Which means I want to say that all of the version control systems from
vcs are migrated now.  (Since tla arch is hosted on download.)
Therefore I think I will set up an iptables block for other services
in order to force finding any unknown issues.

Bob

Re: [Savannah-hackers-public] gnu grep's "grep-devel" mailing list says "nongnu"

[Jim Meyering]

On Tue, Feb 7, 2017 at 8:27 AM, Assaf Gordon  wrote:
> Hello Jim,
>
> On Mon, Feb 06, 2017 at 07:05:29PM -0800, Jim Meyering wrote:
>>
>> Grep is a GNU project, so its "devel" list would be on gnu.org, not on
>> "nongnu.org":
>> Is that something you can help change easily? E.g.,
>>
>>  https://lists.nongnu.org/archive/html/grep-devel/2017-02/msg2.html

Hi Assaf,

I might have google'd "grep-devel" and found an /index link in those results.

> (I'm not very familiar yet with the mailing lists,
> so comments are welcomed)
>
> I believe all mailing lists can be accessed through both gnu and
> nongnu urls, e.g. nongnu for 'coreutils':
>  http://lists.nongnu.org/archive/html/coreutils/

I see that you are right. Thank you.
That makes it easy to avoid the misleading links in the future.

Re: [Savannah-hackers-public] gnu grep's "grep-devel" mailing list says "nongnu"

[Assaf Gordon]

Hello Jim,

On Mon, Feb 06, 2017 at 07:05:29PM -0800, Jim Meyering wrote:

Grep is a GNU project, so its "devel" list would be on gnu.org, not on
"nongnu.org":
Is that something you can help change easily? E.g.,

 https://lists.nongnu.org/archive/html/grep-devel/2017-02/msg2.html


(I'm not very familiar yet with the mailing lists,
so comments are welcomed)

I believe all mailing lists can be accessed through both gnu and
nongnu urls, e.g. nongnu for 'coreutils':
 http://lists.nongnu.org/archive/html/coreutils/


From what I see, the default domain for grep-devel is gnu,

e.g. here:
  http://savannah.gnu.org/mail/?group=grep
and all messages are also accessible with 'gnu', e.g:
  https://lists.gnu.org/archive/html/grep-devel/2017-02/msg2.html

Where did you encounter the nongnu link ?

Checking on the lists server, I see:

   $ cd /var/lib/mailman/lists
   $ ls -l *grep*/domains/* *coreutils*/domains/*
   -rw-r--r-- 1 list list 0 2002-09-18 10:09 bug-coreutils/domains/gnu.org
   -rw-r--r-- 1 list list 0 2004-11-09 12:52 bug-grep/domains/gnu.org
   -rw-r--r-- 1 list list 0 2002-08-09 11:53 coreutils-announce/domains/gnu.org
   -rw-r--r-- 1 list list 0 2010-03-07 09:00 coreutils/domains/gnu.org
   -rw-r--r-- 1 list list 0 2004-11-01 11:15 grep-commit/domains/gnu.org
   -rw-r--r-- 1 list list 0 2016-09-09 10:15 grep-devel/domains/gnu.org

So it seems at least all these are configured the same way.

There is one command about which I'm not sure: withlist/fixurl
as mentioned here:
  https://savannah.gnu.org/maintenance/ListServer/
  (under "switch from nongnu to gnu" section)
I'll see if that part is not correctly configured.

regards,
- assaf