<div dir="ltr">Add a .htaccess HTTP redirect to the HTTPS version for everything (but cgi-bin/) maybe?  That would be the same as the blanket redirect that was happening before.<div><br></div><div>There is some code somewhere that produces nice statistics about where people are from, how many users there, which versions they're using and so on.  At some point I used that to decide whether to support old MacOS versions.  It turned out that there was no point in doing so because people who didn't upgrade their system in years also didn't upgrade Aquamacs...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 27, 2020 at 9:11 PM Win Treese <<a href="mailto:treese@acm.org">treese@acm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks, David (and other contributors to this discussion).<br>
<br>
I added a page to respond to the update check that Aquamacs does, so that the updates work. As David notes, this does require disabling the required use of TLS on <a href="http://aquamacs.org" rel="noreferrer" target="_blank">aquamacs.org</a>. Requests initiated with TLS will stay that way, of course.<br>
<br>
At a minimum, we’ll change the URL to use https for the next release. As David notes, because all the old versions have the http: URL, turning on TLS for the whole site would break that. Judging from the bug reports, there’s still a substantial base of older versions out there.<br>
<br>
I’d certainly like to make a transition to having the site run over TLS at all times, but it’s not clear how to do that in a reasonable way without breaking the old download checks. The code specifically checks that redirects weren’t used, which is not a bad idea for that code, but that makes it hard to work around.<br>
<br>
Thanks,<br>
 - Win<br>
<br>
> On Apr 25, 2020, at 5:18 AM, David Reitter <<a href="mailto:david.reitter@gmail.com" target="_blank">david.reitter@gmail.com</a>> wrote:<br>
> <br>
> The simpler solution (going forward) is to change the update URL going forward to be something like <a href="http://update.aquamacs.org" rel="noreferrer" target="_blank">update.aquamacs.org</a>, and make the update check via HTTP. <br>
>  <br>
> FWIW, this is a little confusing because I’m not sure why it would be any easier to remotely change the URL being checked for update than it would be to remotely update the certificate being trusted. If the update mechanism isn’t working, _any_ client-side change to fix it would seem to need a manual download to get started.<br>
> <br>
> Yes, that's what I meant when I wrote "going forward", and said that a solution is needed to not enforce HTTPS on requests to currentversion.cgi.  On the client-side, it is easy to change that URL, but of course people would have to update Aquamacs to get it.<br>
> <br>
> On Fri, Apr 24, 2020 at 4:16 PM John Wroclawski <<a href="mailto:jtw@csail.mit.edu" target="_blank">jtw@csail.mit.edu</a>> wrote:<br>
> Hi David,<br>
> <br>
>> On Apr 24, 2020, at 4:00 PM, David Reitter <<a href="mailto:david.reitter@gmail.com" target="_blank">david.reitter@gmail.com</a>> wrote:<br>
>> <br>
>> You forget that there are some 100,000 copies of Aquamacs sitting on people's computers.  You can't remotely update which certificates are trusted.<br>
>> <br>
>> The simpler solution (going forward) is to change the update URL going forward to be something like <a href="http://update.aquamacs.org" rel="noreferrer" target="_blank">update.aquamacs.org</a>, and make the update check via HTTP. <br>
> <br>
> FWIW, this is a little confusing because I’m not sure why it would be any easier to remotely change the URL being checked for update than it would be to remotely update the certificate being trusted. If the update mechanism isn’t working, _any_ client-side change to fix it would seem to need a manual download to get started.<br>
> <br>
> (But, having said that, I do agree that the simplest short-term thing to do is almost surely to change the website so that the (current) update URL is loaded via HTTP..)<br>
> <br>
> (But, having said _that_, I do also recognize that many people would prefer to see it be HTTPS in the end notwithstanding the code-signing, so maybe sometime there'll be motivation to wire the whole thing into macOS certificate validation so it’ll all “just work” going forward..)<br>
> <br>
> Cheers, -John<br>
> <br>
> <br>
> _____________________________________________________________<br>
> MacOSX-Emacs mailing list<br>
> <a href="mailto:MacOSX-Emacs@email.esm.psu.edu" target="_blank">MacOSX-Emacs@email.esm.psu.edu</a><br>
> <a href="https://email.esm.psu.edu/mailman/listinfo/macosx-emacs" rel="noreferrer" target="_blank">https://email.esm.psu.edu/mailman/listinfo/macosx-emacs</a><br>
> List Archives: <a href="http://dir.gmane.org/gmane.emacs.macintosh.osx" rel="noreferrer" target="_blank">http://dir.gmane.org/gmane.emacs.macintosh.osx</a><br>
> <br>
> _____________________________________________________________<br>
> MacOSX-Emacs mailing list<br>
> <a href="mailto:MacOSX-Emacs@email.esm.psu.edu" target="_blank">MacOSX-Emacs@email.esm.psu.edu</a><br>
> <a href="https://email.esm.psu.edu/mailman/listinfo/macosx-emacs" rel="noreferrer" target="_blank">https://email.esm.psu.edu/mailman/listinfo/macosx-emacs</a><br>
> List Archives: <a href="http://dir.gmane.org/gmane.emacs.macintosh.osx" rel="noreferrer" target="_blank">http://dir.gmane.org/gmane.emacs.macintosh.osx</a><br>
<br>
<br>
_____________________________________________________________<br>
MacOSX-Emacs mailing list<br>
<a href="mailto:MacOSX-Emacs@email.esm.psu.edu" target="_blank">MacOSX-Emacs@email.esm.psu.edu</a><br>
<a href="https://email.esm.psu.edu/mailman/listinfo/macosx-emacs" rel="noreferrer" target="_blank">https://email.esm.psu.edu/mailman/listinfo/macosx-emacs</a><br>
List Archives: <a href="http://dir.gmane.org/gmane.emacs.macintosh.osx" rel="noreferrer" target="_blank">http://dir.gmane.org/gmane.emacs.macintosh.osx</a><br>
</blockquote></div>