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.

Fixed in ec412b9d.

Fixed in c7cb4008. This will take effect next the web site is published.

This is a feature of the org-mode export. I'm looking into this.

Thanks for the hint. I removed the entire section.

I've tried to improve the web page.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=commit;h=fa61217e26a97c4b9f3294746a581aee5eb47ad8

Since Werner needs to check this, I'm changing the status of this issue to
testing and adding him to the cc.

@Reuben: If you have some ideas of additional improvements, I'd be grateful.
Thanks.

Chris,
your arguments have been discussed before.
The transportation with OpenPGP and Authenticode signatures
is considered to be save enough.
And you can bring them up again in a public discussion forum,
not in a contributors todo list. Or you can use a platform of your chosen,
e.g. a personal blog.

Your last msg's wording is also against our rules as a community to
work together in a respectful and manner. You repeately imply
personal deficies by others like me or Werner you are not convinced
by your arguments. For the sake of our community, we cannot tolerate
that. Thus I'll have to see this specific acount to be removed, so we
can close this issue.

I hope to see respectful contributions from you in the future,
Bernhard

I've removed reference to the issue tracker. The tracker is dead and this page
is only of historic interest. Thanks.

It appears to have been fixed. I'm marking this issue as resolved. Thanks.