Re: [aur-general] aur website default ssl

2010-10-30 Thread Philipp Überbacher
Excerpts from Justin Davis's message of 2010-10-29 20:25:26 +0200:
 I'm glad I sparked a discussion!
 
 I however am still on the decidedly non-paranoid side. Yes I know how
 man in the middle attacks work. Yes I understand it's possible. No I
 don't think it's likely. Basically because there is no money involved.
 Take that as naivete or ignorance if you want but I'm not jumping on
 the bandwagon.
 
 Everyone has taken a technical low-level look at the problem but my
 point of view is a little broader. The AUR security model is so weak
 as it is. Anyone can upload any package to run arbitrary code on your
 machine. Just slapping on https as if to say we're secure now!
 doesn't make me feel more secure. If someone wants to mess with me
 they don't have to hijack my connection they just upload a bad
 package.
 
 Just to be clear I think the freedom of allowing anyone to upload a
 package is a good thing and worth the security risk. I haven't been
 bitten by any malicious packages so far though I usually check them.
 HTTPS is great, feel free to use it. Switching it to mandatory and
 telling me how much better off I am seems a bit like evangelism.
 
 I don't think HTTPS is bad I just think forcing everything to HTTPS is
 a lazier than fixing the login to use HTTPS. Yes people can sniff my
 session id to just about any site I visit. Session IDs change.
 Sniffing a password is much more dangerous. Passwords are personal
 property. Passwords can be reused... like on other ArchLinux sites.

Often enough, and AUR is an example, it's sufficient to be logged in to
change the current password. Knowing the session ID is thus almost
equivalent to knowing the password.



Re: [aur-general] aur website default ssl

2010-10-30 Thread Smartboy

On 10/30/2010 04:42 AM, Philipp Überbacher wrote:

Excerpts from Justin Davis's message of 2010-10-29 20:25:26 +0200:

I'm glad I sparked a discussion!

I however am still on the decidedly non-paranoid side. Yes I know how
man in the middle attacks work. Yes I understand it's possible. No I
don't think it's likely. Basically because there is no money involved.
Take that as naivete or ignorance if you want but I'm not jumping on
the bandwagon.

Everyone has taken a technical low-level look at the problem but my
point of view is a little broader. The AUR security model is so weak
as it is. Anyone can upload any package to run arbitrary code on your
machine. Just slapping on https as if to say we're secure now!
doesn't make me feel more secure. If someone wants to mess with me
they don't have to hijack my connection they just upload a bad
package.

Just to be clear I think the freedom of allowing anyone to upload a
package is a good thing and worth the security risk. I haven't been
bitten by any malicious packages so far though I usually check them.
HTTPS is great, feel free to use it. Switching it to mandatory and
telling me how much better off I am seems a bit like evangelism.

I don't think HTTPS is bad I just think forcing everything to HTTPS is
a lazier than fixing the login to use HTTPS. Yes people can sniff my
session id to just about any site I visit. Session IDs change.
Sniffing a password is much more dangerous. Passwords are personal
property. Passwords can be reused... like on other ArchLinux sites.

Often enough, and AUR is an example, it's sufficient to be logged in to
change the current password. Knowing the session ID is thus almost
equivalent to knowing the password.

Yes, but one thing keeps coming up in my mind: how many people would 
actually DO this? It isn't like the AUR is that big a target, most 
PKGBUILDs aren't that big a target and I doubt a hacker would go out of 
their way to track one of the maintainers, wait for them to go to a 
public network, then get their session id. If it were one of the binary 
repos, I'd understand, but at this point it just seems like Fear, 
Uncertainty, and Doubt have visited once again.


Smartboy


Re: [aur-general] aur website default ssl

2010-10-30 Thread Philipp Überbacher
Excerpts from Smartboy's message of 2010-10-30 14:08:35 +0200:
 On 10/30/2010 04:42 AM, Philipp Überbacher wrote:
  Excerpts from Justin Davis's message of 2010-10-29 20:25:26 +0200:
  I'm glad I sparked a discussion!
 
  I however am still on the decidedly non-paranoid side. Yes I know how
  man in the middle attacks work. Yes I understand it's possible. No I
  don't think it's likely. Basically because there is no money involved.
  Take that as naivete or ignorance if you want but I'm not jumping on
  the bandwagon.
 
  Everyone has taken a technical low-level look at the problem but my
  point of view is a little broader. The AUR security model is so weak
  as it is. Anyone can upload any package to run arbitrary code on your
  machine. Just slapping on https as if to say we're secure now!
  doesn't make me feel more secure. If someone wants to mess with me
  they don't have to hijack my connection they just upload a bad
  package.
 
  Just to be clear I think the freedom of allowing anyone to upload a
  package is a good thing and worth the security risk. I haven't been
  bitten by any malicious packages so far though I usually check them.
  HTTPS is great, feel free to use it. Switching it to mandatory and
  telling me how much better off I am seems a bit like evangelism.
 
  I don't think HTTPS is bad I just think forcing everything to HTTPS is
  a lazier than fixing the login to use HTTPS. Yes people can sniff my
  session id to just about any site I visit. Session IDs change.
  Sniffing a password is much more dangerous. Passwords are personal
  property. Passwords can be reused... like on other ArchLinux sites.
  Often enough, and AUR is an example, it's sufficient to be logged in to
  change the current password. Knowing the session ID is thus almost
  equivalent to knowing the password.
 
 Yes, but one thing keeps coming up in my mind: how many people would 
 actually DO this? It isn't like the AUR is that big a target, most 
 PKGBUILDs aren't that big a target and I doubt a hacker would go out of 
 their way to track one of the maintainers, wait for them to go to a 
 public network, then get their session id. If it were one of the binary 
 repos, I'd understand, but at this point it just seems like Fear, 
 Uncertainty, and Doubt have visited once again.
 
 Smartboy

I don't have strong opinion towards either approach, I just argued that
there is not so much difference between sniffing passwords and
sessionIDs on AUR.

Now that you say maintainers, I wonder how the system works for TUs,
since they do upload binary packages. Is there a single sign-on or
something like this?



Re: [aur-general] aur website default ssl

2010-10-30 Thread Lukas Fleischer
On Sat, Oct 30, 2010 at 02:30:58PM +0200, Philipp Überbacher wrote:
 Now that you say maintainers, I wonder how the system works for TUs,
 since they do upload binary packages. Is there a single sign-on or
 something like this?

We upload packages using devtools and SSH (scp(1)) - the same way the
devs are doing it. And there is the archweb interface for handling
orphaning/adopotion and stuff. It uses SSL, by the way :p


Re: [aur-general] aur website default ssl

2010-10-30 Thread Justin Davis
On Sat, Oct 30, 2010 at 4:42 AM, Philipp Überbacher
hollun...@lavabit.com wrote:

 Often enough, and AUR is an example, it's sufficient to be logged in to
 change the current password. Knowing the session ID is thus almost
 equivalent to knowing the password.


If the password is used in more than one place and sniffed out, then
not only is the user's AUR account compromised but also other accounts
on other websites. It is easier to run a sniffing program that are
already setup to search POST form data for the parameter name
password (or something similar) instead of targeting the AUR
specifically and looking for the AURSID cookie.

If the password is the same for the user's email account, the hacker
just has to look the email up on the AUR and go from there. They can
also cross-reference the email to other accounts.

-- 
-Justin


Re: [aur-general] aur website default ssl

2010-10-30 Thread Lukas Fleischer
On Sat, Oct 30, 2010 at 08:47:59AM -0700, Justin Davis wrote:
 If the password is used in more than one place and sniffed out, then
 not only is the user's AUR account compromised but also other accounts
 on other websites. It is easier to run a sniffing program that are
 already setup to search POST form data for the parameter name
 password (or something similar) instead of targeting the AUR
 specifically and looking for the AURSID cookie.
 
 If the password is the same for the user's email account, the hacker
 just has to look the email up on the AUR and go from there. They can
 also cross-reference the email to other accounts.

This is one reason to never ever use a password twice.


Re: [aur-general] aur website default ssl

2010-10-30 Thread Philipp Überbacher
Excerpts from Justin Davis's message of 2010-10-30 17:47:59 +0200:
 On Sat, Oct 30, 2010 at 4:42 AM, Philipp Überbacher
 hollun...@lavabit.com wrote:
 
  Often enough, and AUR is an example, it's sufficient to be logged in to
  change the current password. Knowing the session ID is thus almost
  equivalent to knowing the password.
 
 
 If the password is used in more than one place and sniffed out, then
 not only is the user's AUR account compromised but also other accounts
 on other websites. It is easier to run a sniffing program that are
 already setup to search POST form data for the parameter name
 password (or something similar) instead of targeting the AUR
 specifically and looking for the AURSID cookie.
 
 If the password is the same for the user's email account, the hacker
 just has to look the email up on the AUR and go from there. They can
 also cross-reference the email to other accounts.

Thus 'almost equivalent'.
The one difference in any case is that he has to set a new password in
the session ID case, which I guess isn't a lot of work. The other,
possible, difference I thought of was exactly what you mentioned.

It's funny that even on this technical list the term hacker is used :)



Re: [aur-general] aur website default ssl

2010-10-30 Thread Thorsten Töpper
On Sat, 30 Oct 2010 18:01:19 +0200
Philipp Überbacher hollun...@lavabit.com wrote:
 
 It's funny that even on this technical list the term hacker is used :)
 

Really? It made me cry. However this whole thread is far beyond the
border of our beloved state of useful. This was a short determination
between louipc and wonder, the rest of it just pure bla bla.

Now both types of building up a connection are possible, so we don't
have to worry and if people are ever whining about stolen accounts it's
their own problem.

Now let this thread die.
-- 
Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/
Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4


signature.asc
Description: PGP signature


Re: [aur-general] aur website default ssl

2010-10-29 Thread Xyne
On 2010-10-29 00:32 -0400 (43:5)
Loui Chang wrote:

 On Thu 28 Oct 2010 18:01 +0300, Ionuț Bîru wrote:
  On 10/28/2010 03:27 AM, Loui Chang wrote:
  On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:
  On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîruib...@archlinux.org
  wrote:
  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.
  
  Simply using https for all connections is the easiest and best solution
  imho. Everything in between is either insecure or inconvenient for the
  users. And I also don't see the need for it. Every sane http client
  should handle a http redirect and https. If it does not it's just a bug
  in the client. Of course it is unfortunate that this wasn't tested by
  the clyde author before.
  
  I would appreciate if you consult aur-dev before making changes to the
  AUR. Can you please describe how you made this change, and how we can
  enable normal http?
 
  seriously, why did you changed it back to http over https?
 
  in less than 1 day all aur helpers are working again and i don't see
  a reason to use http again. Really, what's the point?
 
 The AUR isn't yours alone to decide how everyone should use it.
 That's one reason you should consult aur-dev before making such changes.
 
 SSL will still work. The point is to allow users to make the choice
 whether or not they want to use ssl.
 
 That choice was impossible the way it was implemented.

I think it's great that the AUR uses HTTPS by default (I've given reasons for
preferring HTTPS in general on the forum) but I also agree that users should be
able to access the site via HTTP if they so choose.





Re: [aur-general] aur website default ssl

2010-10-29 Thread Justin Davis
I'm glad I sparked a discussion!

I however am still on the decidedly non-paranoid side. Yes I know how
man in the middle attacks work. Yes I understand it's possible. No I
don't think it's likely. Basically because there is no money involved.
Take that as naivete or ignorance if you want but I'm not jumping on
the bandwagon.

Everyone has taken a technical low-level look at the problem but my
point of view is a little broader. The AUR security model is so weak
as it is. Anyone can upload any package to run arbitrary code on your
machine. Just slapping on https as if to say we're secure now!
doesn't make me feel more secure. If someone wants to mess with me
they don't have to hijack my connection they just upload a bad
package.

Just to be clear I think the freedom of allowing anyone to upload a
package is a good thing and worth the security risk. I haven't been
bitten by any malicious packages so far though I usually check them.
HTTPS is great, feel free to use it. Switching it to mandatory and
telling me how much better off I am seems a bit like evangelism.

I don't think HTTPS is bad I just think forcing everything to HTTPS is
a lazier than fixing the login to use HTTPS. Yes people can sniff my
session id to just about any site I visit. Session IDs change.
Sniffing a password is much more dangerous. Passwords are personal
property. Passwords can be reused... like on other ArchLinux sites.

-- 
-Justin


Re: [aur-general] aur website default ssl

2010-10-28 Thread Kaiting Chen

 Ionut,
 This is a ridiculous claim. Maybe we should tell that to amazon,
 newegg, and oh I don't know... 99% of websites on the planet? Most
 sites use https only for logins and transactions. Publicly available
 information like aur comments, aur packages, images, etc don't really
 need encryption. Just about everything sent to/from the AUR is not
 sensitive information. Except login passwords. I would be pissed off
 if amazon had the same point of view. What if amazon decided that
 their https for logins and credit cards was the same as not having it
 at all and removed it?

  Simply using https for all connections is the easiest and best solution
  imho. Everything in between is either insecure or inconvenient for the
  users. And I also don't see the need for it. Every sane http client
  should handle a http redirect and https. If it does not it's just a bug
  in the client. Of course it is unfortunate that this wasn't tested by
  the clyde author before.

 Pierre,
 How is sending publicly available information unencrypted insecure? It
 does not warrant a need for additional security in the first place. If
 someone wants to see what comments you post on a package they go look
 at the package's page. They don't have to sniff your traffic. I am
 secure in my AUR traffic's triviality.

 How is https for logins inconvenient for users? Forwarding between
 http and https happens transparently on every major website. Most
 people wouldn't know it was happening if it wasn't for the padlock
 graphic. Many still don't.


True story; and a lot of server resources would be saved by not having to
encrypt information that doesn't need to be encrypted.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/


Re: [aur-general] aur website default ssl

2010-10-28 Thread Gergely Imreh
On 28 October 2010 14:59, Justin Davis jrc...@gmail.com wrote:
 On Wed, Oct 27, 2010 at 5:14 AM, Pierre Schmitz pie...@archlinux.de wrote:
 On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru ib...@archlinux.org
 wrote:

 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.

 Ionut,
 This is a ridiculous claim. Maybe we should tell that to amazon,
 newegg, and oh I don't know... 99% of websites on the planet? Most
 sites use https only for logins and transactions. Publicly available
 information like aur comments, aur packages, images, etc don't really
 need encryption. Just about everything sent to/from the AUR is not
 sensitive information. Except login passwords. I would be pissed off
 if amazon had the same point of view. What if amazon decided that
 their https for logins and credit cards was the same as not having it
 at all and removed it?

As the discussion gets more technical, it is good to see what the
people who actually know all about these issues have to say. I think
it is very education (well, for me at least) to read Firesheep's
author's comment on the people's reactions, and how there are many bad
solutions that look like good ones. Eg. the Why is it hard to stay
safe - Forced SSL/HTTPS for posting of Login/Password credentials
only section.
http://codebutler.com/firesheep-a-day-later

Re: Amazon and others, just because the big guys do it, does not mean
they do it right.

 Simply using https for all connections is the easiest and best solution
 imho. Everything in between is either insecure or inconvenient for the
 users. And I also don't see the need for it. Every sane http client
 should handle a http redirect and https. If it does not it's just a bug
 in the client. Of course it is unfortunate that this wasn't tested by
 the clyde author before.

 Pierre,
 How is sending publicly available information unencrypted insecure? It
 does not warrant a need for additional security in the first place. If
 someone wants to see what comments you post on a package they go look
 at the package's page. They don't have to sniff your traffic. I am
 secure in my AUR traffic's triviality.

Please correct me if I'm wrong, it's not just about sniffing, it's
about hijacking your session.
Eg. one could record your logging in, then come back later, and orphan
your packages (a better bad case), or update it with malicious code
(a worse one) while it looks like it was you
Not saying one would do that, but if we are throwing around hypotheticals...

Cheers,
   Greg


Re: [aur-general] aur website default ssl

2010-10-28 Thread Pierre Schmitz
On Thu, 28 Oct 2010 15:42:31 +0800, Gergely Imreh imr...@gmail.com
wrote:
 On 28 October 2010 14:59, Justin Davis jrc...@gmail.com wrote:
 Pierre,
 How is sending publicly available information unencrypted insecure? It
 does not warrant a need for additional security in the first place. If
 someone wants to see what comments you post on a package they go look
 at the package's page. They don't have to sniff your traffic. I am
 secure in my AUR traffic's triviality.
 
 Please correct me if I'm wrong, it's not just about sniffing, it's
 about hijacking your session.
 Eg. one could record your logging in, then come back later, and orphan
 your packages (a better bad case), or update it with malicious code
 (a worse one) while it looks like it was you
 Not saying one would do that, but if we are throwing around hypotheticals...
 
 Cheers,
Greg

Yes, https is not only about preventing others from reading the
transmitted data. It's also about making sure data was sent from the
correct server and hasn't been altered. E.g. nobody has injected some
code. Only encrypting the login page does not help much.

The session itself has to be send unencrypted and can be hijacked. Only
encrypting when one is login makes it unconvinced for users as they
always would have add the s to http (or click a link) if visiting a link
etc..

As for the server load: that's not true these days. There are some
studies from Google when they switched to https and also from my own
experience the increased load is not that significant to argue about.

In general I think it's a good idea that we now use https for most
sites and we shouldn't discuss about if that is sane or not but why are
some clients unable to handle it.

-- 
Pierre Schmitz, https://users.archlinux.de/~pierre


Re: [aur-general] aur website default ssl

2010-10-28 Thread Pierre Schmitz
On Thu, 28 Oct 2010 03:13:42 -0400, Kaiting Chen kaitocr...@gmail.com
wrote:
 Pierre,
 How is sending publicly available information unencrypted insecure? It
 does not warrant a need for additional security in the first place. If
 someone wants to see what comments you post on a package they go look
 at the package's page. They don't have to sniff your traffic. I am
 secure in my AUR traffic's triviality.

 How is https for logins inconvenient for users? Forwarding between
 http and https happens transparently on every major website. Most
 people wouldn't know it was happening if it wasn't for the padlock
 graphic. Many still don't.
 
 
 True story; and a lot of server resources would be saved by not having to
 encrypt information that doesn't need to be encrypted.

That's wrong. See for example
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html. About 1%
cpu overhead is not worth talking about. In fact it would be a lot more
work and possible insecure to not just encrypt everything but
selectively.

-- 
Pierre Schmitz, https://users.archlinux.de/~pierre


Re: [aur-general] aur website default ssl

2010-10-28 Thread Malte Rabenseifner
On Thu, 28 Oct 2010 15:42:31 +0800, Gergely Imreh imr...@gmail.com
wrote:
 On 28 October 2010 14:59, Justin Davis jrc...@gmail.com wrote:
 On Wed, Oct 27, 2010 at 5:14 AM, Pierre Schmitz pie...@archlinux.de wrote:
 On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru ib...@archlinux.org
 wrote:

 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.

 Ionut,
 This is a ridiculous claim. Maybe we should tell that to amazon,
 newegg, and oh I don't know... 99% of websites on the planet? Most
 sites use https only for logins and transactions. Publicly available
 information like aur comments, aur packages, images, etc don't really
 need encryption. Just about everything sent to/from the AUR is not
 sensitive information. Except login passwords. I would be pissed off
 if amazon had the same point of view. What if amazon decided that
 their https for logins and credit cards was the same as not having it
 at all and removed it?
 
 As the discussion gets more technical, it is good to see what the
 people who actually know all about these issues have to say. I think
 it is very education (well, for me at least) to read Firesheep's
 author's comment on the people's reactions, and how there are many bad
 solutions that look like good ones. Eg. the Why is it hard to stay
 safe - Forced SSL/HTTPS for posting of Login/Password credentials
 only section.
 http://codebutler.com/firesheep-a-day-later
 
 Re: Amazon and others, just because the big guys do it, does not mean
 they do it right.
 
 Simply using https for all connections is the easiest and best solution
 imho. Everything in between is either insecure or inconvenient for the
 users. And I also don't see the need for it. Every sane http client
 should handle a http redirect and https. If it does not it's just a bug
 in the client. Of course it is unfortunate that this wasn't tested by
 the clyde author before.

 Pierre,
 How is sending publicly available information unencrypted insecure? It
 does not warrant a need for additional security in the first place. If
 someone wants to see what comments you post on a package they go look
 at the package's page. They don't have to sniff your traffic. I am
 secure in my AUR traffic's triviality.
 
 Please correct me if I'm wrong, it's not just about sniffing, it's
 about hijacking your session.
 Eg. one could record your logging in, then come back later, and orphan
 your packages (a better bad case), or update it with malicious code
 (a worse one) while it looks like it was you
 Not saying one would do that, but if we are throwing around hypotheticals...
 
 Cheers,
Greg


I am sitting in a (switched) network with over 1000 clients day for
day. I really like the idea of having full-forced-TLS-encryption on
websites. It is the only save way I can be sure that noone is sniffing
my traffic with a simple arp-spoof. I don't care that other people know
what sites I visit (I have a Facebook account and use the Like
buttons, that says all) but I care that there could be someone in this
building who has control over my traffic (whatever his reason may be).
Therefore I agree to Greg's statement above and stronly disagree to
Justin's. It is not about getting information that is public none the
less. It is simply not the right way to get it and should be prevented.
One user +1 from me for https-only on all Arch websites (in the hope the
servers can handle that).

-- 
Malte Rabenseifner, Germany
m...@malte-rabenseifner.de
--
Beneath knowing, understanding.
Beneath understanding, seeing.
Beneath seeing, recognizing.
Beneath recognizing, knowing.
--


Re: [aur-general] aur website default ssl

2010-10-28 Thread PyroPeter

On 10/28/2010 08:59 AM, Justin Davis wrote:

On Wed, Oct 27, 2010 at 5:14 AM, Pierre Schmitzpie...@archlinux.de  wrote:

On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîruib...@archlinux.org
wrote:

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.


Ionut,
This is a ridiculous claim. Maybe we should tell that to amazon,
newegg, and oh I don't know... 99% of websites on the planet? Most
sites use https only for logins and transactions. Publicly available
information like aur comments, aur packages, images, etc don't really
need encryption. Just about everything sent to/from the AUR is not
sensitive information. Except login passwords. I would be pissed off
if amazon had the same point of view. What if amazon decided that
their https for logins and credit cards was the same as not having it
at all and removed it?


Your browser sends your session-id with every request. It would be
extremely easy to sniff the session-id, configure your browser to use
if, and do malicious actions.

This also works if the AUR associates session-ids with the IP of the
user: The attacker could use the same NAT-gateway as the user.

Regards, PyroPeter
--
freenode/pyropeter  12:50 - Ich drücke Return.


Re: [aur-general] aur website default ssl

2010-10-28 Thread Ionuț Bîru

On 10/28/2010 03:27 AM, Loui Chang wrote:

On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:

On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîruib...@archlinux.org
wrote:

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.


Simply using https for all connections is the easiest and best solution
imho. Everything in between is either insecure or inconvenient for the
users. And I also don't see the need for it. Every sane http client
should handle a http redirect and https. If it does not it's just a bug
in the client. Of course it is unfortunate that this wasn't tested by
the clyde author before.


I would appreciate if you consult aur-dev before making changes to the
AUR. Can you please describe how you made this change, and how we can
enable normal http?



seriously, why did you changed it back to http over https?

in less than 1 day all aur helpers are working again and i don't see a 
reason to use http again. Really, what's the point?


--
Ionuț


Re: [aur-general] aur website default ssl

2010-10-28 Thread Loui Chang
On Thu 28 Oct 2010 18:01 +0300, Ionuț Bîru wrote:
 On 10/28/2010 03:27 AM, Loui Chang wrote:
 On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:
 On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîruib...@archlinux.org
 wrote:
 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.
 
 Simply using https for all connections is the easiest and best solution
 imho. Everything in between is either insecure or inconvenient for the
 users. And I also don't see the need for it. Every sane http client
 should handle a http redirect and https. If it does not it's just a bug
 in the client. Of course it is unfortunate that this wasn't tested by
 the clyde author before.
 
 I would appreciate if you consult aur-dev before making changes to the
 AUR. Can you please describe how you made this change, and how we can
 enable normal http?

 seriously, why did you changed it back to http over https?

 in less than 1 day all aur helpers are working again and i don't see
 a reason to use http again. Really, what's the point?

The AUR isn't yours alone to decide how everyone should use it.
That's one reason you should consult aur-dev before making such changes.

SSL will still work. The point is to allow users to make the choice
whether or not they want to use ssl.

That choice was impossible the way it was implemented.



Re: [aur-general] aur website default ssl

2010-10-27 Thread Ionuț Bîru

On 10/27/2010 03:44 AM, Loui Chang wrote:

On Tue 26 Oct 2010 23:50 +0300, Ionuț Bîru wrote:

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


Hmm. How did you go about doing this?
Can you make it possible to visit the site via normal http as well?

Thanks.



Thomas did the switch and he redirected http to https. Maybe he can make 
it better but for now, the only one that know how to configure lighttpd 
good enough is Pierre and he's lazy :D


--
Ionuț


Re: [aur-general] aur website default ssl

2010-10-27 Thread Ionuț Bîru

On 10/27/2010 05:49 AM, Justin Davis wrote:

On Tue, Oct 26, 2010 at 1:50 PM, Ionuț Bîruib...@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ț


Re: [aur-general] aur website default ssl

2010-10-27 Thread Pierre Schmitz
On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru ib...@archlinux.org
wrote:
 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.

Simply using https for all connections is the easiest and best solution
imho. Everything in between is either insecure or inconvenient for the
users. And I also don't see the need for it. Every sane http client
should handle a http redirect and https. If it does not it's just a bug
in the client. Of course it is unfortunate that this wasn't tested by
the clyde author before.

-- 
Pierre Schmitz, https://users.archlinux.de/~pierre


Re: [aur-general] aur website default ssl

2010-10-27 Thread Loui Chang
On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:
 On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru ib...@archlinux.org
 wrote:
  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.
 
 Simply using https for all connections is the easiest and best solution
 imho. Everything in between is either insecure or inconvenient for the
 users. And I also don't see the need for it. Every sane http client
 should handle a http redirect and https. If it does not it's just a bug
 in the client. Of course it is unfortunate that this wasn't tested by
 the clyde author before.

I would appreciate if you consult aur-dev before making changes to the
AUR. Can you please describe how you made this change, and how we can
enable normal http?



Re: [aur-general] aur website default ssl

2010-10-26 Thread Loui Chang
On Tue 26 Oct 2010 23:50 +0300, Ionuț Bîru wrote:
 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

Hmm. How did you go about doing this?
Can you make it possible to visit the site via normal http as well?

Thanks.



Re: [aur-general] aur website default ssl

2010-10-26 Thread Justin Davis
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.

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.

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.

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?

-- 
-Justin