On 10/27/2010 05:49 AM, Justin Davis wrote:
On Tue, Oct 26, 2010 at 1:50 PM, Ionuț Bîru<ib...@archlinux.org>  wrote:
Hi,

we are now using default https for aur.archlinux.org. Some aur helpers may
need adjustment, others like cower/slurpy already works as expected.

Kudos for their maintainers for following the aur development

Hi I maintain clyde lately. I try to keep it working anyways. This
mandatory switch to https breaks clyde's AUR support. Clyde's AUR
support is the only reason to use it, really... it is an AUR helper
after all. Forcing all traffic to https is not what I would call
"default". Default would be cool but generally a default option is not
the _only_ option.


Hi, i didn't know that there is another maintainer and i announced personally Digitalkiwi, for more than one month(i believe), that we are switching. He said that is working and it shouldn't be a problem.

I hadn't joined aur-dev. I am assuming the switch was announced there.
I already am a part of this mailing list and most of what I receive
from it is junk to me. I also joined the pacdev mailing list long ago
but filtered that because it fills my mailbox with stuff I don't care
about. All I care about are API changes to libalpm, really, and I
usually just diff the sources to find them.


This switch was mostly discuss it in bugtracker

Out of curiosity I looked at slurpy on github and it hasn't been
updated since July. Cower was updated 4 days ago. If an AUR helper
uses a sufficiently high-level interface they won't need to update
because they get forwarded to the HTTPS URI. Everything is
automagically fixed for them. Clyde is probably the only AUR helper to
suffer from this because of its low-level Luasocket library. Maybe
paktahn as well. Kudos to falconindy at least for updating cower to
use https by default.


That was mostly a rant by me side and is should be ignored :P

I'm glad that logins to the AUR are now encrypted. Previously they
weren't which is always surprising to find out. Other than logins I
could care less if my traffic is sniffed. I know the logic is easier
to just switch _everything_ to HTTPS but could maybe we just use https
for logins? Could you allow HTTPS to be optional (except for logins)
and then give validity to the term "default"?


As i said earlier in a reply to Loui, maybe we can do it better.Having https only for login and then redirecting to http is like not having it at all.

--
Ionuț

Reply via email to