Basically, done.

cgi finished.
translation has been finished except testimonials.

Ha, I need to use 2-23/3 to a run a job every 3 ours and not just 2/3.
Unfortunately the default cron logging does not log faulty log files. Changed that as well.

I translated index.de.org, donate.de.org, and checkout-cc.de.org. I don't see anything missing in procdonate.cgi.

Reference of stripe's checkout.js: https://stripe.com/docs/checkout

I doubt that we will be able to do French. I have implemented the basic framework for de and ja, though. What we need is a switch language button in the menu and well the entire translation. The thing works like this:

In T2844#96255, @marcus wrote:

phabricator already mirrors these repositories, and the mirrors are accessible via https, e.g. https://dev.gnupg.org/source/gnupg.git
How about just pointing to these and leave git.gnupg.org git-only?

phabricator already mirrors these repositories, and the mirrors are accessible via https, e.g. https://dev.gnupg.org/source/gnupg.git
How about just pointing to these and leave git.gnupg.org git-only?

This has been fixed quite some time ago.

Thanks, sounds like you have plans to address all three of the problems then.

Cheers

Yes please.

Shall I look into this?

[I'm doing s@://@: / /@g so that roundup does not complain about this message
having too many links.]

So I did that. There are two problems:

1/ We advertise URLs of the form 'https: / /git.gnupg.org/foo.git', but this URL
contains only the name of the repository as the path. In boa, I need to specify
a non-empty path in the ScriptAlias directive for the path to CGIs, and then the
script itself also needs a non-empty name. Neither pound nor boa seem to have
path-rewriting functionality, so I don't see how we can serve a git repository
using the 'git-http-backend' CGI this way (w/o patching boa that is).

I decided to be pragmatic about it (at least for the moment) and go for URLs of
the form 'https: / /git.gnupg.org/g/it/foo.git', so I can use 'ScriptAlias /g
...', and use 'it' for the script name. However:

2/ Something is fishy with the TLS setup:

% git clone https: / /git.gnupg.org/g/it/ntbtls.git
Cloning into 'ntbtls'...
fatal: unable to access 'https: / /git.gnupg.org/g/it/ntbtls.git/': GnuTLS recv
error (-110): The TLS connection was non-properly terminated.
% wget -O - --tries=1
https: / /git.gnupg.org/g/it/ntbtls.git/info/refs?service=git-upload-pack
--2017-03-16 17:34:02--
https: / /git.gnupg.org/g/it/ntbtls.git/info/refs?service=git-upload-pack
Resolving git.gnupg.org (git.gnupg.org)... 217.69.76.56, 2001:aa8:fff1:2100::56
Connecting to git.gnupg.org (git.gnupg.org)|217.69.76.56|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-git-upload-pack-advertisement]
Saving to: ‘STDOUT’

• [<=> ] 0 --.-KB/s 001e# service=git-upload-pack

000000d506bb9a836981e48c2e6939fb21480d97253a4588 HEADmulti_ack thin-pack
side-band side-band-64k ofs-delta shallow no-progress include-tag
multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.8.0.rc3
003f06bb9a836981e48c2e6939fb21480d97253a4588 refs/heads/master
00449fb1c710e821f27ac7039c2b3bdd584ccc6012e6 refs/tags/ntbtls-0.1.0
004750ad7a2206bac7682195e8285af96e0d790891b3 refs/tags/ntbtls-0.1.0^{}
00449b970fc16d5c257651c9377ec97fb255d2425583 refs/tags/ntbtls-0.1.1
00475de470fbeb7b6d92070206414d130dfb53d96e69 refs/tags/ntbtls-0.1.1^{}

• [ <=> ] 592 --.-KB/s in 0.003s

2017-03-16 17:34:02 (214 KB/s) - Read error at byte 592 (The TLS connection was
non-properly terminated.).Giving up.

Yes, please do. Look at trithemius so see how to run several boa instances.
You really need to give the binary another name.

I looked into this. Pound is configured to relay these requests to
127.0.0.2:80, but no backend listens there. git http-backend can serve these
requests, is a cgi program and thus needs a webserver to run.

https://git-scm.com/docs/git-http-backend

I believe we could setup another instance of boa for the purpose of running it.

Werner, if you agree to that plan I could give it a shot.

Done.

Thank you.
I have removed the hint about the login problems.

Please give Bernhard and me a head-up (outside this issue) as soon as you know
which authentication method/providers you will support.

I can confirm that I can login again.

@justus: Thanks for the quick fix!

Thomas: Done. I was able to login to the wiki using my roundup credentials again.

(I cannot assign the issue to you.)

Werner: Will you provide a new authentication methods for people participating
in the GnuPG communit?

What should we do until then?
The wiki is potentially interesting each day. It is probably easiest for the
users if you restore the old behaviour until a new authentication method for the
GnuPG-Community is available. Otherwise users must change their credentials two
times (First to the separate wiki authentication now and then to the new one
once it is available.)

What is the estimated roadmap for replacing roundup?

Note that roundup will be decommissioned in the near future, thus the wiki needs
to switch to another authentication method anyway.

Please remove the drm.info logo and url. This is an FSFE project and (iirc)
they stopped the DRM project and thus tehre is no budget for doing even trivial
things.
They scared the voluntary sysadmins mostly away.

I updated the logo and link to PlusServer.

The remaining issue is the link to drm.info. I contacted the people running the
site in January, and I was told that the issue will be dealt within a few months.

I added the following snippet to our pound configuration in the ListenHTTP
section for IPv4:

1. Justus: Redirect all jenkins request to https. Service HeadRequire "Host:.*jenkins.gnupg.org" Redirect 301 "https://jenkins.gnupg.org" End

I hope I didn't break anything. Jenkins is much nicer to use now :)

jenkins is redirected from kerckhoffs to soro using pound features. Please
check out /etc/pound/pound.cfg on kerckhoffs. The jenkins server on soro is
running on a non-standard port - may be this is the reason for the wrong redirect.

I can't easily test this because I am living in the same network.

Regarding HSTS (HTTP Strict Transport Security): The Jenkins server needs to
generate that header

I don't know about HSTS, but I'd love to see a forced redirect.

It seems Jenkins sometimes generates a redirect that strips the httpS off, e.g.
go to https://jenkins.gnupg.org/manage, click on [Manage Plugins] (the link
itself looks fine), but one is for some reason redirected to
http://jenkins.gnupg.org/pluginManager/.

Done. It is now redirected via refresh, javascript, or a link to click. Thus
most users won't see the gnu pages at all (because most(tm) use Javascript)

I do not understand your request. Do you mean we shall use HSTS and forced
redirection to https for jenkins?

The web page has been updated.

Done. Note that the https is only to the frontend the backend is reached
unencrypted. We can't easily change this.

It's been a year since last update. Still an issue. Maybe someone should send
an email to gnupg-commits-owner@gnupg.org ?

It is simply not implemented, yet. We need to do this of course instead of
fixing the website.

We are waiting for Plusserver or one of their sub-companies to tell us how to
proceeed.

There are two http links left on the page. One (drm.info) is unfortunately
unavailable over https. The other (openit.de) seems to no longer exist, as the
company has merged with another one and is only a forward to plusserver. Probably
that simply should be changed to https://www.plusserver.com/ (and maybe the logo
as well).

Fixed. The index is now re-created daily for all directories.

Both 2.1.11 and 2.1.12 are not in the index, so the update
was missed during the release process.
Werner, you probably know best where to place it in the release process,
so that it is not forgotten. An alternative would be to use a directory listing
module of the webserver which does this more dynamically (and caches the result).

Let us use T2305 for the index update.

Also, index.html in https://www.gnupg.org/ftp/gcrypt/gnutls/ is not up to date:
it does not list v3.5 but the tarball is there:

https://www.gnupg.org/ftp/gcrypt/gnutls/v3.5/gnutls-3.5.tar.xz

Not a bug. "iff" is used math as an abbreviation for "if and only if ..."

Thanks. Fixed in working directory; will show up soon.

In case you want to submit more typo fixes, please collect some of them and put
them into one report.

DoS via Tor - sorry.

Fixed in 81797af.