Hacker Newsnew | past | comments | ask | show | jobs | submit | acct's commentslogin

Or Coke (and a caffeine pill), or whatever you prefer. Bad coffee is a perplexing choice.


Thermogenic diet pills are crap for direct weightloss but they are effectively an energy drink in pill form without the water or sugar.


Irrelevant amounts of so. Any driving school teaches using engine braking for increased fuel efficiency and decreased wear of brakes. Manual clutches still last for far longer than even high-end automatic ones.


There is absolutely nothing wrong with HTTP. You are supposed to verify signing keys after you download them anyway, regardless of your source and tranfer method.

Yes, that may often be hard, or nearly impossible. WOT sadly often only works for people you can personally verify anyway.

(With HTTPS, you better wish the author chose a reputable and more expensive certificate authority which can be trusted not to give certificates without proper proof of address ownership. Otherwise, verifying the website certificate may be as hard has verifying personal keys.)


MIT GPG keys are unverified. HTTPS would only add a false sense of security - you are supposed to verify the keys after you download them (yes, it's not easy, depending on how much verification you require).


But surely you must trust your SSH client, and thus its developers.


Right now it is pretty much a binary choice - trust and install. Don't trust and don't install. I trust the developer to have implemented the SSH protocol correctly -- I have to trust them that much. But I don't see why I should have trust them enough to give them full permissions to my machine. Sandboxing (with permissions) would allow the application to run and access a port, nothing else.


Surely it does. Did you think GETs are transferred before the encrypted connection is established?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: