This is still the case.

As far as I can tell, http://gnupg.org/documentation/manpage.en.html is no
longer linked from
http://gnupg.org/documentation/guides.en.html. Closing.

According to Kristian, there are currently two main keyservers.

The most widely used keyserver is SKS. It's homepage is here:
https://bitbucket.org/skskeyserver/sks-keyserver/overview

A new keyserver being developed in go is hockeypuck:
https://github.com/hockeypuck/hockeypuck

Werner: Is adding these under https://www.gnupg.org/related_software/tools.html
appropriate?

The new URL is now also an old URL.

Fixed in the repo. Will show up with the next site rebuild. Thanks.

D333: 691_0001-Remove-Korean-documentations.patch

The manual is not maintained anymore and thus we don't apply fixes, sorry.

D332: 689_r899.html.patch

This is still open: http://files.gpg4win.org/gpg4win-2.2.6.exe
So this stays open: T1858

You said: "TAKE THIS TO A MAILING LIST"
You then said: "I have see your post."
You are behaving with extreme deception and dishonesty.
Leave this issue to someone else - your emotions have destroyed your
objectivity.

Nope, I have see your post.

I asked you several times to not continue here.
Again: PLEASE STOP THAT NOW and keep this bug closed.

Stop closing this bug.
I did take this to the list.
You or whoever runs/moderates it is blocking my post.

DO NOT CLOSE THIS until such time as windows users are prevented from
getting your security solution over totally insecure channels.

This is not a game you know - it's an almost absolute certainty that your
careless security attitude will GET PEOPLE KILLED.

Let the person who fixes the insecure distribution problem be the one who
closes this bug. It is not appropriate that your ego needs to win some
puerile argument at the expense of other peoples safety and lives.

This has nothing to do with gnupg.org. And if you have followed the discussions
you will have noticed that I requested to add TLS support for gpg4win. Please
keep this bug closed and TAKE THIS TO A MAILING LIST - if you want audience for
this problem address it in the public and not on this bug tracker! I can't do
anything for you here.

I checked. Here are some inconvenient "facts" for you:

http://gpg4win.org/download.html
http://files.gpg4win.org/gpg4win-2.2.6.exe
http://files.gpg4win.org/gpg4win-2.2.6.exe.sig

https://www.gnupg.org/download/mirrors.html *
There is NOT EVEN ONE SINGLE SSL LINK on the above page!!!!!

Dude - you need to take yourself off this project. If you are more
interested in winning some stupid pride fight than protecting users of a
security product, you deserve no place on the team.

Let me quote YOUR OWN WORDS back to you:
" Instead of providing a not very secure HTTPS access to the files... "

You work on a security product, and you expect us to accept that because you
somehow believe the same security that protects every single other thing on
the web is "not very secure", that it's all fine and hunky-dory for you to
distribute yours over PLAIN UNAUTHENTICATED TEXT, and to expect us to USE
this unauthenticated code to verify it's own sigantures, which also come the
same way (http://files.gpg4win.org/gpg4win-2.2.6.exe.sig)

Here's some more facts - just one tiny list...

ftp://ftp.gnupg.ca/
ftp://ftp.ring.gr.jp/pub/net/gnupg/
http://www.ring.gr.jp/pub/net/gnupg/
ftp://gd.tuwien.ac.at/privacy/gnupg/
http://gd.tuwien.ac.at/privacy/gnupg/
ftp://mirrors.dotsrc.org/gcrypt/
http://mirrors.dotsrc.org/gcrypt/
ftp://ftp.jyu.fi/pub/crypt/gcrypt/
ftp://mirror.cict.fr/gnupg/

http://artfiles.org/gnupg.org
ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt/

ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/

http://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/

...

and the list snakes on

Do not close this bug. Your emotions are too heated to be rational now.

Please check the facts. I am closing this bug. If you want to raise that again
please feel free do so at gnupg-users@gnupg.org.

gpg itself, and all it's SHA sums, and all your keys, are being distributed
over unauthenticated plain-text channels which are 100% vulnerable to
undetectable modification in transit.

There is NO EXCUSE for any security product to be distributed in such a
blatantly irresponsible way.

EVERY PLAINTEXT ENDPOINT NEEDS TO BE SHUT DOWN

Anyway, the FTP server is meanwhile also accessible via https://gnupg.org/ftp -
if you know the file name.

The home page with the list of all docs is just fine.

And it uses an older version of Debian on too old hardware.
No user accounts there put only public information. Thus it is not a primary
attack target.

1. Your web server doesn't support ECC DH key exchange.
2. Your web server is using DH key exchange with a 1024-bit group.

The issue is not resolved: if "gpg --recv-keys" is not sufficient, then some
other step must be added to the instructions, as currently they do not work, at
least not for this non-expert user.

There are two problems:

1. This sentence does not make sense: "You should see a message indicating that

the signature is good and made by of the signing keys." (Maybe the solution is
as simple as deleting "of"?)

2. The following instructions are too brief: "Make sure that you have the right

key, either by checking the fingerprint of that key with other sources or by
checking that the key has been signed by a trustworthy other key." Someone who
is trying to download GnuPG as part of bootstrapping a secure environment for
the first time (e.g. so they can download other software such as Tor in a
trustworthy way), will not know how to follow either of those suggestions.
Concrete instructions are needed.

If I simply download the GPG sources and corresponding signature, and run the
gpg --verify command that is given, I get the following output:

gpg: directory `/home/rrt/.gnupg' created
gpg: new configuration file `/home/rrt/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/rrt/.gnupg/gpg.conf' are not yet active during
this run
gpg: keyring `/home/rrt/.gnupg/pubring.gpg' created
gpg: Signature made Wed 01 Jul 2015 13:56:58 BST using RSA key ID 4F25E3B6
gpg: Can't check signature: public key not found
gpg: Signature made Thu 02 Jul 2015 05:31:06 BST using RSA key ID 33BD3F06
gpg: Can't check signature: public key not found

In other words, it doesn't seem to do anything useful.

This is on purpose. --recv-key is not sufficient.

Please send mail and follow the instructions on the page.

should be fixed for quite some time now.

Should all be fixed in the meantime.

Thanks. Fix pushed to the repo.

I don't get the message while signed in of course, but going incognito
or the next day, the message is back.

How is any browser supposed to trust a self-signed certificate if the
issuer is unknown to the browser? Is there something I can add to my
OS that will let it know you are the issuer?

I have seen this issue before, even on bank sites, going back 5 years
at least. I would like to know if there is a general solution.

You have marked this resolved so may not look at it anymore. I should
not have made this seem to be a Chrome issue. Firefox is the same and
their detailed message is more helpful:

bugs.gnupg.org uses an invalid security certificate.

The certificate is not trusted because it is self-signed.
The certificate is only valid for the following names:
www.g10code.com, g10code.com, ftp.g10code.com, bugs.g10code.com,

git.g10code.com

(Error code: sec_error_unknown_issuer)

Chrome? I don't know. Using self-signed certificates is pretty common.

You say Chrome should be able to handle it, but it's not. I am using
the most up-to-date version of Chrome available for Linux: Version
40.0.2214.6 dev (64-bit), and it is not handling the certificate
properly. The wording of the "advanced" message indicates this is the
fault of my operating system. If this is a bug of Arch Linux, what
package would I file the bug against?

The entire X.509 based system is unsafe - it just does not work.
To save the costs and trouble I use a self-signed certificate for this site.

Or is that that Chrome is not able to handle an expiration time set to the day
of First Contact? Icanga has such a year 2038 problem, but I bet Chrome can
handle it.

Thanks, The fix will be online soon.

--load-extension is a dummy function. It does not do anything.

Yes, please add your information to the webpage, incl. the exact version numbers
and their dependency/relation to IDEA/idea.c/...

For usability reasons, the "load extension" option could check for idea.c
parameter and reject this explicitly in those versions that don't need/support
this anymore. This might be an option in contrast to change all old forum
entries around in the internet discussing this topic.... ;-)
But this would be another bug report, I guess.

Thanks.