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.

The link currently works for me. Either the link was fixed or the target has
been restored. Either way, the issue is now resolved. Thanks.

I've removed it. Thanks.

Bernhard - this is an issue of security, it is not a place for you to
exercise corruption by using your influence over administrators to shut down
opinions you disagree with.

You have made a statement that I am absolutely confident that no security
professional will support: "We will keep the non-TLS access, because there
are some people that will lose access otherwise.". Aside form this
statement being almost certainly totally untrue, this is nevertheless NOT a
valid reason to continue to distribute a security product over known
compromiseable channels. If anyone cannot get GPG because of TLS (which I
doubt), that is NOT a reason to for everyone to get GPG over an insecure
channel. Like I've said before, security-downgrade attacks are the most
effective weapon used by adversaries. Do not make is so easy for them.

Let me suggest a resolution to this problem, since we seem to be at a
stalemate:

Let us pick a security professional who is known and trusted. You can write
down your case for why you do not want to use TLS, and I will write down my
case why I want TLS to be mandatory, and we will each give our cases to this
professional.

If they pick your case, I will let you close this ticket and I will not come
back.

If they pick my case, you will resign from the GnuPG project and not come
back.

Deal?

Chris,

the admins tell me that it is easiest to remove your user account
to withdraw updating rights to this issue. This I may be forced to do,
unless we find a better solution for civility and availability of this tracker.

Regards,
Bernhard

Chris,
as we want to keep this community functional, we require a basic politeness
and respect for the provided tools like this tracker.

As you keep insisting on an argument that Werner and myself
cannot follow and you do not respect that this tracker is the
todo list of the active contribution, we have to protect
our contribution community for repeated obstruction of our goals.
I will see if I can get this tracker issue closed.

Feel free to bring matters like this up on the public mailing list or
your own other channels.

Best,
Bernhard

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

Chris, please take this to one of the mailing lists (gnupg-usewrs@gnupg.org).
You want a discussion about this and thus the bug tracker is not the right media
for you. Please do not re-open this bug again.

We provide all kind of means to verify the software and the default is now to
use the also-easy-to-subvert https for those who are not able to verify
signatures or checksums.

Also feel free to provide a verified copy of the software from your own boxes
and announce that to the Gpg4win lists.

Mate - it's this simple. For as long as you're distributing a security
product over plaintext insecure channels, this bug needs to stay open.

TLS will NOT prevent anyone downloading this, no matter how hard you cling
to that irrational idea. If you work for someone who is exploiting this
attack vector SHAME ON YOU!!!

Stop wasting everyones time. If you don't want to fix this, go away and do
something else, stop preventing someone who *can* fix it from actually doing
that by messing with this ticket.

Dear Chris <coward@anon.im>,

this is the todo list of active contributors
and to be useful to them, they get to decide what is tracked.

My argument that there are some people that are in situations
where they cannot get a TLS connection (behind a firewall or not having
the right software), they still get the same, integrity protected distribution.
All other can use TLS, if they want to. So it is more people overall
that have access.

Convince a few other active contributors of GnuPG or Ggp4win that
you are still having a valid point for the todo list. If so, open a new
issue. Reopening this one is not helpful.

Best,
Bernhard

"We will keep the non-TLS access, because there are some people
that will lose access otherwise."

LOL

You know that GnuPG is a security product, right?

I challenge your assumption. Nobody will loose access, but securing
downloads will make EVERYONE mass-loads safer.

Heck dude - there's this search engine, maybe you've heard of it? It's
called GOOGLE. They make you use this thing, maybe you've heard of it too?
It's called TLS.

Just get rid of the unsafe stuff Bernhard, this isn't a game, peoples lives
really do balance on this stuff. Start acting responsibly.

We will keep the non-TLS access, because there are some people
that will lose access otherwise. This would be security loss in availability.

I appreciate that you checking what we do and that you want to help the initiative.
In order that many people can do so in a constructive way
the tracker is here to support the active contributors,
which will have the final say what they are going to see as a todo item or not.
We'll probably change some of the web pages and will move some more services
over time, but there is not much point in tracking it here.
Please respect this decision.

Sounds like a plan!

Get rid of all the insecure delivery mechanisms ( e.g.
http://files.gpg4win.org/gpg4win-2.2.6.exe ), which you can now safely do
because you've got secure ones (well done), then (and only then) you can
close this bug!

https://files.gpg4win.org/

I disagree, MitM cannot fake the origin so there is no gain in integrity
by using TLS. And if MitM can substitute traffic, it can also block TLS traffic
so there is also no again in availability.

Let me quote from T1858 (cnd on Nov 12 2015, 10:21 AM / Roundup):

So there is https://files.gpg4win.org/gpg4win-2.2.6.exe

For as long as easy MitM can substitute traffic, signing the EXE is a
pointless waste of time.

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

Gpg4win installers have been code-signed with Authenticode for years and thus are
as securely authenticable as you trust the Microsoft code signing certificate chain
. (If the Microsoft code-signing certificate chaing is broken, your system is wide
open as it secures a lot.)

Gpg4win and GnuPG binaries are signed and additional available over TLS channels
(which provides less integrity protection.)

This link has been removed long ago. Nevertheless thanks for the bug report.

https://www.gnupg.org/documentation/manpage.en.html is way out of date. Is
there a way to automatically generate this page (it needs to be converted to the
.org format).

I can't find any current information about PocketConsole or PocketGnuPG on the
web. I'm assuming that the software is not supported anymore and, as such, I've
removed the link.

I've added this now.

That is okay.

I've confirmed that this is still a problem.

Current URL was reported in 1495. Closing this issue and leaving that one open.

Duplicate of T1495

This is still the case.

This now works. Closing.