This is false, see the `stack solver` and `stack init --solver` commands. Currently it's using cabal's dependency solver under the surface, but there is work in progress (by multiple parties) to implement a new SAT-based solver, see: https://github.com/commercialhaskell/stack/issues/116
Even without --verify, stackage-update is providing a far more secure setup than what you get from cabal update today (since it downloads over SSL). I didn't want to make GPG configuration an impediment to people using this tool, thereby pushing them towards something even less secure.
Longer term, we need a better answer, most likely using a config file to state your preference, and eventually switching the default to --verify.
I don't want to re-hash an old argument, but in my opinion dropping the gpg-key at a well known location secured by ssl (or better yet, bundled with all binary packages of haskell), and using gpg for trust is better in many ways.
Suddenly secure off-line distribution (think CDs), bittorrent, plain http/ftp... becomes [ed:trivial to] secure (if not private).
And anchoring everything at a gpg key makes the trust chain simpler. No longer can a rouge CA distribute signed software updates, you only have to trust your kernel, haskell and gpg -- not the usually large and somewhat arbitrary bundle of CA certs that come with the OS etc.
[Ed: not to mention: the gpg signing key can live "mostly offline" - the ssl key is "always online". Only the server hosting the gpg key (if first-trust is anchored in ssl) is critical for distribution]
[Ed2: You already ask people to install trusted binaries (to boostrap cabal/haskell) -- surely a gpg-implementation can be squeezed in there?]
> I didn't want to make GPG configuration an impediment to people using this tool...
Maybe consider arranging distribution packages to automatically make GPG configuration available, and then default to --verify on in distributions by default?
I think this answers your question: this new phase of hiring is based on new customer work we need to fill, plus increased community involvement we're planning to have. This is not based on any new investor funding.
This round of hiring is for engineers with experience. We are likely going to be opening another round of hiring in the near future (reading: next 5-9 months) for less experienced developers, but the details around that are still murky.
Actually, the ideas for LTS Haskell came out of conversations I had with Duncan and Mark at ICFP. The original idea was to create a GPS Haskell that would encompass a "best of both worlds." LTS Haskell is a first step towards that, and I'm hoping that Haskell Platform and Hackage ultimately fold this stuff back in.
Sounds good. I had assumed you were heading in this direction. The approach was something Duncan and I wanted to try in 2007/2008 but we didn't have resources at the time. Now the infrastructure is there, automatically identifying stable sets, tagging and releasing them is a good step. If you can get to the point of computing the next HP set in the same fashion, that will be a big win for stability.
The clientsession package (which is what we use) both encrypts and applies a hash to the payload. Hashing prevents users from tampering with the data, and encrypting prevents inspection of the data. This means that you can even store sensitive data in a cookie without worrying if it's being compromised. (Not to say I recommend that practice, but it is possible.)
There is of course some performance overhead to encrypting, but Felipe's skein package has been highly optimized, and Yesod is still able to achieve ~50,000 req/sec on modest hardware. (Apologies for not having more accurate numbers, I haven't run our benchmark suite on EC2 in over a year.)
The content of the cookie isn't compromised, but you can trivially sidejack a cookie on an unencrypted connection and access the information through the website itself, in essence stripping any security. Arguably encrypting the cookie is a waste of processor time, but more importantly I think you may be giving people a false sense of security. The proper way to do secure interactions is via SSL, and I'm not sure encrypted cookies vs simply HMACed cookies gives you any true security advantage (as session storage or anything else).
Yes, that's precisely what I'm saying. So, let me put it differently: what security advantage does an encrypted session cookie confer? I see two possibilities:
- Someone who hijacks a request with the cookie in it cannot see the data in the cookie. But they can access the site as the user, so there is no real world benefit to this fact.
- Someone on the same computer cannot see the data in the cookie. But again, they have the cookie value, so they can access the site as the user, so there is again no real world benefit to the fact that they can't see the data in the cookie itself, because they can interact with the site and see the data there.
I guess I'm just looking for an example scenario where the cookie being encrypted offers a concrete benefit from a security standpoint.
I might be wrong here but I think it prevents against a user tampering their own cookie. Say I store User_Id:5 in a cookie and pass it over an ssl connection. The user can still change from User_Id:5 to User_Id:6 and get user 6's account info. Typically you would have to store a non guessable token instead to avoid this. I think by encrypting the cookie you provide the non-guessable part of the equation without having to think about it. This isn't really a benefit from a security standpoint (as in it doesn't provide more security), but it is convenient.
Could be wrong here, I'm not very familiar with Yesod.
i can think of only one case: that in which the site owners dont want the user (or sidejacker in case of a non-SSL connection) to see some data they wish to put in the cookie.
i'd cannot think of a web app i worked on where this was needed.
(the hashing is cool though -- tinker prevention is common to be a-good-thing)
Notably, this would only happen if you have data in the user's session that the user themselves cannot get to by using the site. I confess I can't think of any such session data, but I suppose it could exist.
And yes, some sort of HMAC is pretty much mandatory if you're going to do client-side session storage securely, no question.
I can't answer with certainty what the author means, but the next set of features planned for Yesod is to have tighter client-side integration. We also agree that's where web app development is headed, but we wanted to start with a solid server-side framework before branching into the client side.
I don't think anyone's actually done it, because most of our users really like Hamlet. That said, switching should be a piece of cake. All you need to do is get the textual result from the templating language you're using and apply preEscapedText to it. Since we use blaze-html under the surface, any templating languages using that library's types will automatically work with Yesod.
Of course, support for type-safe URLs will vary by templating languages, so you may have to manually render URLs yourself, but that's doable via getUrlRender.
