SSL support for hackage and cabal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SSL support for hackage and cabal

Eli Frey
Hello all,

It recently came to my attention that hackage is http only.  I would love to do anything I can to help hackage support https. What is the process for volunteering with the IHG (I imagine this is the avenue for helping with hackage/haskell.org).

If the IHG is having dificulty getting an SSL certificate, GlobalSign (ful disclosure, they are my employer) provides free certificates to FOSS projects.

here is a link: https://www.globalsign.com/ssl/ssl-open-source/

I am also concerned that cabal does not have support for SSL, but hackage must come first and at least then a sufficiently paranoid person can download their packages over https and ad them to their cabal sandboxes.

Cheers,
Eli

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Scott Lawrence
Hello,

On the other side: cabal, at least, uses the HTTP package, and I've been
(slowly) working on adding SSL support.

On Sat, 2 Nov 2013, Eli Frey wrote:

> Hello all,
>
> It recently came to my attention that hackage is http only.  I would love
> to do anything I can to help hackage support https. What is the process for
> volunteering with the IHG (I imagine this is the avenue for helping with
> hackage/haskell.org).
>
> If the IHG is having dificulty getting an SSL certificate, GlobalSign (ful
> disclosure, they are my employer) provides free certificates to FOSS
> projects.
>
> here is a link: https://www.globalsign.com/ssl/ssl-open-source/
>
> I am also concerned that cabal does not have support for SSL, but hackage
> must come first and at least then a sufficiently paranoid person can
> download their packages over https and ad them to their cabal sandboxes.
>
> Cheers,
> Eli
>

--
Scott Lawrence
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Jason Dagit-3
In reply to this post by Eli Frey



On Sat, Nov 2, 2013 at 12:25 PM, Eli Frey <[hidden email]> wrote:
Hello all,

It recently came to my attention that hackage is http only.  I would love to do anything I can to help hackage support https. What is the process for volunteering with the IHG (I imagine this is the avenue for helping with hackage/haskell.org).

If the IHG is having dificulty getting an SSL certificate, GlobalSign (ful disclosure, they are my employer) provides free certificates to FOSS projects.

Yes! And they have graciously given us an SSL certificate. We are very pleased by that :)

Having an SSL certificate is a recent thing for us and the infrastructure team is currently busy wrapping up other tasks. We do have folks assigned to putting the cert in place and configuring everything, they just need a bit more time :) (More volunteers would help too, but that's longer term.)

I am also concerned that cabal does not have support for SSL, but hackage must come first and at least then a sufficiently paranoid person can download their packages over https and ad them to their cabal sandboxes.

Yes, this is the next part to tackle.

Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Eli Frey
> Yes! And they have graciously given us an SSL certificate. We are very pleased by that :)

Who-da thunk it :).

Configuring ssl can be tricky, especially getting it right. I'de love to help if you have any problems.  We use sslcheck.x509labs.com internally to make sure everything is working correctly.  It even has step-by-step instructions on how to fix some problems.

> On the other side: cabal, at least, uses the HTTP package, and I've been (slowly) working on adding SSL support.

Oh lovely!  I can not find your work through the github repos, but I'd love to take a look and see if I can help.


On Sat, Nov 2, 2013 at 12:58 PM, Jason Dagit <[hidden email]> wrote:



On Sat, Nov 2, 2013 at 12:25 PM, Eli Frey <[hidden email]> wrote:
Hello all,

It recently came to my attention that hackage is http only.  I would love to do anything I can to help hackage support https. What is the process for volunteering with the IHG (I imagine this is the avenue for helping with hackage/haskell.org).

If the IHG is having dificulty getting an SSL certificate, GlobalSign (ful disclosure, they are my employer) provides free certificates to FOSS projects.

Yes! And they have graciously given us an SSL certificate. We are very pleased by that :)

Having an SSL certificate is a recent thing for us and the infrastructure team is currently busy wrapping up other tasks. We do have folks assigned to putting the cert in place and configuring everything, they just need a bit more time :) (More volunteers would help too, but that's longer term.)

I am also concerned that cabal does not have support for SSL, but hackage must come first and at least then a sufficiently paranoid person can download their packages over https and ad them to their cabal sandboxes.

Yes, this is the next part to tackle.

Jason


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Johan Tibell-2
In reply to this post by Eli Frey
Hi,

On Sat, Nov 2, 2013 at 8:25 PM, Eli Frey <[hidden email]> wrote:
I am also concerned that cabal does not have support for SSL, but hackage must come first and at least then a sufficiently paranoid person can download their packages over https and ad them to their cabal sandboxes.

We need an SSL library that cabal can depend on. This means that it needs to be cross-platform, not pull in too many other depedencies, etc. Someone needs to investigate the options and perhaps write a new binding if needed.

-- Johan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Scott Lawrence
I believe tls and tls-extra (http://hackage.haskell.org/package/tls-1.1.5)
satisfy those requirements, being pure haskell.

On Sat, 2 Nov 2013, Johan Tibell wrote:

> Hi,
>
> On Sat, Nov 2, 2013 at 8:25 PM, Eli Frey <[hidden email]> wrote:
>
>> I am also concerned that cabal does not have support for SSL, but hackage
>> must come first and at least then a sufficiently paranoid person can
>> download their packages over https and ad them to their cabal sandboxes.
>>
>
> We need an SSL library that cabal can depend on. This means that it needs
> to be cross-platform, not pull in too many other depedencies, etc. Someone
> needs to investigate the options and perhaps write a new binding if needed.
>
> -- Johan
>

--
Scott Lawrence
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Scott Lawrence
In reply to this post by Eli Frey
On Sat, 2 Nov 2013, Eli Frey wrote:

> Oh lovely!  I can not find your work through the github repos, but I'd love
> to take a look and see if I can help.

Nothing posted online yet. I'll slap a fork up and post here as soon as it's
working enough for multiple eyes to be meaningful (bug finding/fixing etc).

--
Scott Lawrence
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Johan Tibell-2
In reply to this post by Scott Lawrence
True. Although to be honest I want something true and tested when it comes to crypto.

On Sat, Nov 2, 2013 at 9:41 PM, Scott Lawrence <[hidden email]> wrote:
I believe tls and tls-extra (http://hackage.haskell.org/package/tls-1.1.5) satisfy those requirements, being pure haskell.


On Sat, 2 Nov 2013, Johan Tibell wrote:

Hi,

On Sat, Nov 2, 2013 at 8:25 PM, Eli Frey <[hidden email]> wrote:

I am also concerned that cabal does not have support for SSL, but hackage
must come first and at least then a sufficiently paranoid person can
download their packages over https and ad them to their cabal sandboxes.


We need an SSL library that cabal can depend on. This means that it needs
to be cross-platform, not pull in too many other depedencies, etc. Someone
needs to investigate the options and perhaps write a new binding if needed.

-- Johan


--
Scott Lawrence


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

John Wiegley-3
>>>>> Johan Tibell <[hidden email]> writes:

> True. Although to be honest I want something true and tested when it comes
> to crypto.

Although in this case, the worst scenario is that we return to parity with the
status quo (i.e., the security lib is worthless and we revert back to having
no security).

--
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Scott Lawrence
One could argue that the potential for a false sense of security could make
(very) bad encryption worse than no encryption.

Personally, I've always been a bit uncomfortable with the small number of
widely-used implementations (AFAIK OpenSSL and GnuTLS combined account for
pretty much all TLS-using open-source software), and I think pushing another
one into wider usage would be a good thing (while acknowledging that it's
likely more vulnerable than the older implementations).

On Sun, 3 Nov 2013, John Wiegley wrote:

>>>>>> Johan Tibell <[hidden email]> writes:
>
>> True. Although to be honest I want something true and tested when it comes
>> to crypto.
>
> Although in this case, the worst scenario is that we return to parity with the
> status quo (i.e., the security lib is worthless and we revert back to having
> no security).
>
> --
> John Wiegley
> FP Complete                         Haskell tools, training and consulting
> http://fpcomplete.com               johnw on #haskell/irc.freenode.net
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

--
Scott Lawrence
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Donn Cave-4
In reply to this post by Johan Tibell-2
Quoth Johan Tibell,
[ ... Re Haskell TLS implementation ]

> True. Although to be honest I want something true and tested when it comes
> to crypto.

Don't believe in security by obscurity?  

How strongly do you feel about the cross platform and dependency issues?

When I needed SSL encryption, I whipped up a little module with foreign
calls to OpenSSL.  For an ordinary client, which is all I use it for any
more, it's a simple interface -- init, connect, read, write, a couple
error functions.  I have to link -lssl -lcrypto.  The great thing about
this is, not only do I have a high degree of confidence in the implementation,
I don't expect it to _ever_ change in a way that will inconvenience me.
If my application ever needs to work on a platform with a different SSL,
just need a new module with init/connect/write etc.

Does that seem like a possibility, just write minimal interfaces to
existing platform standard SSL implementations, and move on to more
interesting problems?  Or is this really an area with interesting problems
of its own that I'm missing?

        Donn
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Mike Izbicki
What's the standard practice for how FOSS software actually keeps a private key private?  This requirement is rather counter cultural, and so I imagine it's often not done in a robust way. 

Do you typically just trust that whomever is in charge of the project didn't make any mistakes in the installation and didn't sellout the key to someone else?  Or is there a way for other eyes to verify that everything happened correctly without exposing the private key to every contributor? 


On Sun, Nov 3, 2013 at 9:02 AM, Donn Cave <[hidden email]> wrote:
Quoth Johan Tibell,
[ ... Re Haskell TLS implementation ]

> True. Although to be honest I want something true and tested when it comes
> to crypto.

Don't believe in security by obscurity?

How strongly do you feel about the cross platform and dependency issues?

When I needed SSL encryption, I whipped up a little module with foreign
calls to OpenSSL.  For an ordinary client, which is all I use it for any
more, it's a simple interface -- init, connect, read, write, a couple
error functions.  I have to link -lssl -lcrypto.  The great thing about
this is, not only do I have a high degree of confidence in the implementation,
I don't expect it to _ever_ change in a way that will inconvenience me.
If my application ever needs to work on a platform with a different SSL,
just need a new module with init/connect/write etc.

Does that seem like a possibility, just write minimal interfaces to
existing platform standard SSL implementations, and move on to more
interesting problems?  Or is this really an area with interesting problems
of its own that I'm missing?

        Donn
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Scott Lawrence
Even if you do expose the private key to other people, there's no way for them
to know that the administrator didn't also send it somewhere else -- you can't
prove that somebody hasn't duplicated information, without making sure they
don't have access to the information (which the admin must).

At the end of the day, trusting admins is what almost always happens. The
other route is for packages to be individually signed by developers. As I
recall, that's been explicitly discussed and informally rejected here before,
on the grounds that it makes the uploading process significantly more
cumbersome for many people.

On Sun, 3 Nov 2013, Mike Izbicki wrote:

> What's the standard practice for how FOSS software actually keeps a private
> key private?  This requirement is rather counter cultural, and so I imagine
> it's often not done in a robust way.
>
> Do you typically just trust that whomever is in charge of the project
> didn't make any mistakes in the installation and didn't sellout the key to
> someone else?  Or is there a way for other eyes to verify that everything
> happened correctly without exposing the private key to every contributor?
>
>
> On Sun, Nov 3, 2013 at 9:02 AM, Donn Cave <[hidden email]> wrote:
>
>> Quoth Johan Tibell,
>> [ ... Re Haskell TLS implementation ]
>>
>>> True. Although to be honest I want something true and tested when it
>> comes
>>> to crypto.
>>
>> Don't believe in security by obscurity?
>>
>> How strongly do you feel about the cross platform and dependency issues?
>>
>> When I needed SSL encryption, I whipped up a little module with foreign
>> calls to OpenSSL.  For an ordinary client, which is all I use it for any
>> more, it's a simple interface -- init, connect, read, write, a couple
>> error functions.  I have to link -lssl -lcrypto.  The great thing about
>> this is, not only do I have a high degree of confidence in the
>> implementation,
>> I don't expect it to _ever_ change in a way that will inconvenience me.
>> If my application ever needs to work on a platform with a different SSL,
>> just need a new module with init/connect/write etc.
>>
>> Does that seem like a possibility, just write minimal interfaces to
>> existing platform standard SSL implementations, and move on to more
>> interesting problems?  Or is this really an area with interesting problems
>> of its own that I'm missing?
>>
>>         Donn
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>

--
Scott Lawrence
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Niklas Hambüchen
On 03/11/13 17:49, Scott Lawrence wrote:

> Even if you do expose the private key to other people, there's no way
> for them to know that the administrator didn't also send it somewhere
> else -- you can't prove that somebody hasn't duplicated information,
> without making sure they don't have access to the information (which the
> admin must).
>
> At the end of the day, trusting admins is what almost always happens.
> The other route is for packages to be individually signed by developers.
> As I recall, that's been explicitly discussed and informally rejected
> here before, on the grounds that it makes the uploading process
> significantly more cumbersome for many people.

It is clear that putting HTTPS on the Hackage web site is the first step.

Then comes cabal SSL support, and then maybe in the future the package
signing.

Once again, could we please just go ahead and push forward that the SSL
certificate gets on the web server?

As Jason Dagit said:

   We do have folks assigned to putting the cert in place and
configuring everything, they just need a bit more time
   (More volunteers would help too, but that's longer term.)

Who are the folks, and what needs more time?

There seem to be a lot of volunteers around who would like to help (for
example, I have asked for this multiple times over the last years and
this thread shows that there are many more people interested in it).
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Carter Schonwald
Theres a Haskell-infrastructure team that is now managing much of the community infrastructure, talk with them if you want to get involved. they're often found on the #haskell-infrastructure irc channel on freenode and they're amazingly responsive (despite being all volunteers)


On Sun, Nov 3, 2013 at 1:19 PM, Niklas Hambüchen <[hidden email]> wrote:
On 03/11/13 17:49, Scott Lawrence wrote:
> Even if you do expose the private key to other people, there's no way
> for them to know that the administrator didn't also send it somewhere
> else -- you can't prove that somebody hasn't duplicated information,
> without making sure they don't have access to the information (which the
> admin must).
>
> At the end of the day, trusting admins is what almost always happens.
> The other route is for packages to be individually signed by developers.
> As I recall, that's been explicitly discussed and informally rejected
> here before, on the grounds that it makes the uploading process
> significantly more cumbersome for many people.

It is clear that putting HTTPS on the Hackage web site is the first step.

Then comes cabal SSL support, and then maybe in the future the package
signing.

Once again, could we please just go ahead and push forward that the SSL
certificate gets on the web server?

As Jason Dagit said:

   We do have folks assigned to putting the cert in place and
configuring everything, they just need a bit more time
   (More volunteers would help too, but that's longer term.)

Who are the folks, and what needs more time?

There seem to be a lot of volunteers around who would like to help (for
example, I have asked for this multiple times over the last years and
this thread shows that there are many more people interested in it).
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Gershom Bazerman
In reply to this post by Niklas Hambüchen
On various topics:

Security is a multifaceted beast with many related issues, depending on
which attack vectors we're concerned about, with what degree of assurance.

Ultimately, we rely on trusted parties, and so of course don't have a
defense (other than 'many eyes') if someone were to hand e.g. SPJ or
Austin or the maintainer of a key package in the Platform a swiss bank
account with some quantity of gold sufficient to induce them to put in a
backdoor, or perhaps just steal their computers, passwords, and keys to
put in a backdoor themselves.

That said, even if we consider that we 'trust' key individuals involved,
as well as the security of their keys and identity, we still have other
vectors to prevent. Here's my summary of what I understand (thanks to
Duncan for helping me sort this out on IRC. Most insights his, all
omissions mine).

1) Only those individuals who own packages should be able to upload
their packages.
     A) This is solvable soon and directly by adding SSL to hackage, so
that they can upload (via the web interface) in a secure manner.
     B) To upload securely via "cabal upload" we'll need cabal to have
access to the right secure protocols.
     C) The "easy" answer here is to shell out to curl or the like, and
place the obligation on the end user to have the right security-enabled
binaries on their system.
     D) Other than that, we need to use e.g. "tls" and "tls-extras"
     E) To trust those, we should encourage outreach to the security
community as a whole to examine, harden, etc. the code. It is in the
interests of many, not just in the haskell world, to have more,
different, and reliable open-source implementations of our open
protocols for secure communication.
     F) Even if we don't 'trust' tls sufficiently to bless it for the
platform, we can still bake it into platform-distributed cabal-install
binaries, as better than nothing.

2) When I download a package, I should be able to trust that the package
I download is one uploaded by a verified uploader.
     A) This is about signing and verification, not a secure protocol as
such.
     B) It requires a different design. The library support is easier
than that for SSL. However, there are more options for "how verified" we
want the chain of trust to be -- is it sufficient for hackage to sign
the tarballs, or do we want to let users sign their own tarballs and
allow verification of that, etc.

On a related topic:

On 11/3/13 1:19 PM, Niklas Hambüchen wrote:
> There seem to be a lot of volunteers around who would like to help
> (for example, I have asked for this multiple times over the last years
> and this thread shows that there are many more people interested in it).

What we need is not a 'drive by' volunteer just for one-time certificate
deployment (which is easy). Volunteers for hackage and cabal to tackle
the bigger technical issues described above would be much more
important. Join the cabal-devel mailinglist, or hang out in #hackage on
irc, or both.

On reducing the load on the core infra team, what would be best is
people able to devote a consistent (even if small) amount of time on a
prolonged basis. Someone familiar with various virtualization
technologies and deployment on linux would be ideal. Join the
#haskell-infrastructure channel on irc, the haskell-infrastructure list
hosted by galois, email [hidden email], or email me directly, and
we'll see where you might fit in best. It's great if people want to jump
in -- there's plenty of work to be done. Let's centralize what people
have to offer, so that we can work most efficiently!

Cheers,
Gershom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Brandon Allbery
In reply to this post by Donn Cave-4
On Sun, Nov 3, 2013 at 12:02 PM, Donn Cave <[hidden email]> wrote:
not only do I have a high degree of confidence in the implementation,
I don't expect it to _ever_ change in a way that will inconvenience me.

Not familiar with how OpenSSL handles compatibility, I take it? I have no such confidence.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Eli Frey
In reply to this post by Gershom Bazerman
> Theres a Haskell-infrastructure team that is now managing much of the community infrastructure, talk with them if you want to get involved. they're often found on the #haskell-infrastructure irc channel on freenode and they're amazingly responsive (despite being all volunteers)

> What we need is not a 'drive by' volunteer just for one-time certificate deployment (which is easy). Volunteers for hackage and cabal to tackle the bigger technical issues described above would be much more important. Join the cabal-devel mailinglist, or hang out in #hackage on irc, or both.

Good points, I'll quit back seat driving :P.



On Sun, Nov 3, 2013 at 11:00 AM, Gershom Bazerman <[hidden email]> wrote:
On various topics:

Security is a multifaceted beast with many related issues, depending on which attack vectors we're concerned about, with what degree of assurance.

Ultimately, we rely on trusted parties, and so of course don't have a defense (other than 'many eyes') if someone were to hand e.g. SPJ or Austin or the maintainer of a key package in the Platform a swiss bank account with some quantity of gold sufficient to induce them to put in a backdoor, or perhaps just steal their computers, passwords, and keys to put in a backdoor themselves.

That said, even if we consider that we 'trust' key individuals involved, as well as the security of their keys and identity, we still have other vectors to prevent. Here's my summary of what I understand (thanks to Duncan for helping me sort this out on IRC. Most insights his, all omissions mine).

1) Only those individuals who own packages should be able to upload their packages.
    A) This is solvable soon and directly by adding SSL to hackage, so that they can upload (via the web interface) in a secure manner.
    B) To upload securely via "cabal upload" we'll need cabal to have access to the right secure protocols.
    C) The "easy" answer here is to shell out to curl or the like, and place the obligation on the end user to have the right security-enabled binaries on their system.
    D) Other than that, we need to use e.g. "tls" and "tls-extras"
    E) To trust those, we should encourage outreach to the security community as a whole to examine, harden, etc. the code. It is in the interests of many, not just in the haskell world, to have more, different, and reliable open-source implementations of our open protocols for secure communication.
    F) Even if we don't 'trust' tls sufficiently to bless it for the platform, we can still bake it into platform-distributed cabal-install binaries, as better than nothing.

2) When I download a package, I should be able to trust that the package I download is one uploaded by a verified uploader.
    A) This is about signing and verification, not a secure protocol as such.
    B) It requires a different design. The library support is easier than that for SSL. However, there are more options for "how verified" we want the chain of trust to be -- is it sufficient for hackage to sign the tarballs, or do we want to let users sign their own tarballs and allow verification of that, etc.

On a related topic:


On 11/3/13 1:19 PM, Niklas Hambüchen wrote:
There seem to be a lot of volunteers around who would like to help (for example, I have asked for this multiple times over the last years and this thread shows that there are many more people interested in it).

What we need is not a 'drive by' volunteer just for one-time certificate deployment (which is easy). Volunteers for hackage and cabal to tackle the bigger technical issues described above would be much more important. Join the cabal-devel mailinglist, or hang out in #hackage on irc, or both.

On reducing the load on the core infra team, what would be best is people able to devote a consistent (even if small) amount of time on a prolonged basis. Someone familiar with various virtualization technologies and deployment on linux would be ideal. Join the #haskell-infrastructure channel on irc, the haskell-infrastructure list hosted by galois, email [hidden email], or email me directly, and we'll see where you might fit in best. It's great if people want to jump in -- there's plenty of work to be done. Let's centralize what people have to offer, so that we can work most efficiently!

Cheers,
Gershom

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Vincent Hanquez
In reply to this post by Scott Lawrence
On 2013-11-03 17:48, Scott Lawrence wrote:
> One could argue that the potential for a false sense of security could
> make (very) bad encryption worse than no encryption.
>
Well. No, false sense of security is bad, however is has no link with
your absolute level of security.

Even bad cryptographic implementation provide some security in a sense,
at worse by obscurity
(which is very poor security, but not zero), and In the best case (of
the bad) a rather hard problem
for resource-less people.

Now i'm not saying that bad implementations are OK, and certainly I hope
that's not the case in tls,
but in the context where we got nothing, just as John Wiegley rightfully
mentioned, the risk is
quite small.

it's rather sad to see the "i'ld rather have *no* security whatsoever,
than maybe have some" hard line.

> Personally, I've always been a bit uncomfortable with the small number
> of widely-used implementations (AFAIK OpenSSL and GnuTLS combined
> account for pretty much all TLS-using open-source software), and I
> think pushing another one into wider usage would be a good thing
> (while acknowledging that it's likely more vulnerable than the older
> implementations).
>

That, and also that half of openssl CVE in the past 20 years were buffer
overflow/underflow.
Nothing to do with cryptography, but rather just simple memory management.
I think this got to give some security points for a (mostly) haskell
implementation.

--
Vincent
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: SSL support for hackage and cabal

Vincent Hanquez
In reply to this post by Donn Cave-4
On 2013-11-04 01:02, Donn Cave wrote:
> How strongly do you feel about the cross platform and dependency issues?
Quite ? I think that would be rather bad to have cabal have ssl on unix, but
not on MacOSX and Windows.

> When I needed SSL encryption, I whipped up a little module with foreign
> calls to OpenSSL.  For an ordinary client, which is all I use it for any
> more, it's a simple interface -- init, connect, read, write, a couple
> error functions.  I have to link -lssl -lcrypto.  The great thing about
> this is, not only do I have a high degree of confidence in the implementation,
> I don't expect it to _ever_ change in a way that will inconvenience me.
> If my application ever needs to work on a platform with a different SSL,
> just need a new module with init/connect/write etc.
>
> Does that seem like a possibility, just write minimal interfaces to
> existing platform standard SSL implementations, and move on to more
> interesting problems?  Or is this really an area with interesting problems
> of its own that I'm missing?
>
I think that's the best alternative (provided wide spread non support
for tls),
except there's no platform standards (think about chromium, and mozilla
cases for a very similar problem), and it's probably going to be
"interesting"
to maintain (as in it take probably quite a bit of resource for browsers
to keep on top).

--
Vincent
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12